Wikidata:Project chat

From Wikidata
Jump to: navigation, search
Shortcut: WD:PC
Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Requests for deletions and mergers can be made here.
IRC channel: #wikimedia-wikidata <IRC-connect>
 Start a new discussion
Edit
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at May.


Administrators'
noticeboard

Translators'
noticeboard

Bureaucrats'
noticeboard

Requests
for permissions

Requests
for deletions

Properties
for deletion

Requests
for comment

Project
chat


Contents

Notability question [edit]

Is it allowed for someone to make an item with no links simply to put it as an answer to a statement? Q11774062 seems to have been created just so it can be put in Q777402. Del♉sion23 (talk) 18:02, 14 May 2013 (UTC)

I would also have used it in every county in P132 in Arkansas, so I see no problem with it. -- Lavallen (block) 18:20, 14 May 2013 (UTC)
See WD:Notability. US counties, along with their political attributions are defined at the state level, so I would say it meets both criterion 2 and criterion 3. Of course, adding other claims to the item would make sense. --Zolo (talk) 18:21, 14 May 2013 (UTC)
One could interpret the third paragraph of WD:N that way but this is hardly viable because the data is not atomized and thereby violates database principles. --Sixsi6ma (talk) 18:38, 14 May 2013 (UTC)
What does it mean that the data is not atomized, and which principles are violated?
BTW I added two statements to county of Arkansas (Q11774062): subclass of (P279) county (Q47168) and is in the administrative unit (P131) Arkansas (Q1612). I am a little unsure of the latter. Is it OK to link a class to an instance this way? Byrial (talk) 19:42, 14 May 2013 (UTC)
I would think part of (P361) is more appropriate than is in the administrative unit (P131) in this case, but I am unsure. --Zolo (talk) 19:59, 14 May 2013 (UTC)
I would have used country (P17) Arkansas (Q1612) if Arkansas had been an independant nation. But I guess part of (P361) is sufficient. -- Lavallen (block) 17:23, 15 May 2013 (UTC)
I have added type of administrative division (P132) and country (P17). These properties are recommended by the places task force. Filceolaire (talk) 09:09, 18 May 2013 (UTC)

--ValterVB (talk) 19:36, 21 May 2013 (UTC)

Jurors 1–12 [edit]

What about creating an item for every single role in a film? Someone has made a new empty item for each of the juror roles in 12 Angry Men (see the "starring" section). Imagine this for every character in the world... We have to have some cut-off level for notability here, I think that a different data type should be used that doesn't require a new item for every character ever played. Del♉sion23 (talk) 18:05, 15 May 2013 (UTC)

Items for Jurors 1-12 was created after recommendation at Property talk:P453#Type of property. But I think that it is questionable if such film roles are notable. Byrial (talk) 18:47, 15 May 2013 (UTC)
I think that items with no sitelinks should be the exception, not the rule. If cases like these are allowed then they will quickly become the rule rather than the exception. Seeing as we don't yet have the capacity to add proper references to items, it is currently very difficult to verify the notability of an item unless there are some sitelinks. I wouldn't be against the roles in this case being written in black text. Not everything needs to be a clickable blue link. Del♉sion23 (talk) 19:04, 15 May 2013 (UTC)

There are 31 links left in User:Byrial/Empty items now. They all lack sitelinks but are used in other items. I can see why some have been kept, but the majority have questionable notability. There has to be a better way to define notability than WD:N point 3. That point pretty much opens the door to anything being notable so long as it is used in a statement or query. Del♉sion23 (talk) 19:45, 15 May 2013 (UTC)

Actually I made the recommendation at Property talk:P453#Type of property to create these items since I think they meet the third criteria of WD:N (structural need). I guess the best solution would be allowing a property to have multiple datatypes (both item and multilanguage text in this case), but it is impossible according to the development team. A workaround would be creating another property called "role (text)" which use multilanguage text as datatype, but it would make many tasks (e.g. query) more difficult since we have to deal with both properties all the time, and it would be even worse if we adopt this method to create other properties such as "author (text)", "father (text)", "stated in (text)", etc. I think creating items like Jurors 1-12 is not prefect, but it's the best solution we have which makes things simple and clear. --Stevenliuyi (talk) 20:29, 15 May 2013 (UTC)

I have created the role for that movie to have an example. I don't like this solution maybe is better a multilanguage string with a qualifier that link to item if exist. Something like :

  • Actor: xxx (property)
    • Role: yyyy (qualifier)
      • Link (or Item): Qzzz (qualifier)

--ValterVB (talk) 22:21, 15 May 2013 (UTC)

I do not agree that there is a structural need for the Juror items. The statements about the actors in the movie 12 Angry Men would work fine without supplying them with a role qualifier, so there is no need for the qualifier. You can add the role qualifier for roles which already are notable per other criteria. But all roles in any notable movie is not automatically notable. Byrial (talk) 07:57, 17 May 2013 (UTC)
I think that in cases like this we could use a general-purpose "juror" item for the "role" qualifier, just in case someone wants to make a query for, actors who played a juror. --Zolo (talk) 20:27, 17 May 2013 (UTC)
I agree that in some cases we can use generic items, however in this case I prefer to use specific items. Take a look at two example claims I've just added at the 1954 teleplay Twelve Angry Men and the 1997 television film 12 Angry Men (along with the 1957 film 12 Angry Men) , I think it's the only way we can query different actors who played the same role (Juror 1). --Stevenliuyi (talk) 23:10, 18 May 2013 (UTC)
If we add "only" notable role, we will have problem to compile infobox in Wikipedia (my opinion) where normaly are reported all the roles. --ValterVB (talk) 19:36, 21 May 2013 (UTC)

Band [edit]

Does a band get characterised under persons or organisations? 130.88.141.34 09:46, 17 May 2013 (UTC)

Organizations. Also check out Property_talk:P107#Examples for answers to a few questions of the same nature. Pichpich (talk) 13:55, 17 May 2013 (UTC)
That's only for GND. One can use subclass of persons. Infovarius (talk) 19:58, 17 May 2013 (UTC)
I'm pretty sure the question was for GND. I'm also sure that using P279 is the wrong thing to do. The Beatles are a subclass of persons? That makes no sense. Pichpich (talk) 23:10, 17 May 2013 (UTC)
I agree, and I think subclass is generally for use with term items. Danrok (talk) 01:21, 18 May 2013 (UTC)
May be part of (P361)? or subset? Infovarius (talk) 19:47, 18 May 2013 (UTC)
That makes even less sense. The Beatles are part of a person? The Beatles are a subset of persons? I know you're not a big fan of GND (neither am I) but it's just silly to try to force the issue. The Beatles are a an organization and more specifically a rock band. That's all we need. (well I guess The Beatles would argue that all we need is love) Pichpich (talk) 15:32, 19 May 2013 (UTC)

Items about more than one person [edit]

What should main type (GND) (P107) be for items about more than one named people, like Mary-Kate and Ashley Olsen (Q208415)?

I am inclined to delete statements about sex and profession etc. from such items, as I think that these things should be statet for the individual persons (which can be found with consists of (P527) property), and not for the group item. Do you agree? Byrial (talk) 10:49, 18 May 2013 (UTC)

I agree with you about sex and profession statements. I think that, for this kind of case we should have an item for the reunion which is considered as a list and an item for each member. So, the properties about member(s) of the reunion would be set in the item of each member of the reunion and not in the item about of the reunion. But, if we choose this system, we will have to modify bots to make them don't had properties related to member to the reunion item. Tpt (talk) 10:59, 18 May 2013 (UTC)
I agree. The property for sex should only be used for individual people, not for groups (even if the members of the group are all the same gender, for example Spice Girls) Del♉sion23 (talk) 11:47, 18 May 2013 (UTC)

On en.wiki, articles on multiple people aren't included in categories that only make sense for individuals. Instead, the redirects about each individual are categorized. For instance en:Sacco and Vanzetti is not included in the category "1891 births" (but the redirect en:Nicola Sacco is) or the category "1888 births" (but en:Bartolomeo Vanzetti is). The equivalent on Wikidata would be items for the individuals. Pichpich (talk) 14:25, 18 May 2013 (UTC)

It would have been nice to be able to create a relation between those redirects and the related items here on Wikidata. For me, that is more important, than being able to have interwiki to redirects. I see to many items where the subjects has been merged only because "number of bytes" is a measure of quality on Wikipedia. -- Lavallen (block) 15:03, 18 May 2013 (UTC)
I think that it makes a lot of sense for wikipedia to group associated items in the same article even if it makes things more difficult for wikidata. The change to the software to let us link to redirects should, however, help with this when it is implemented. To respond to the original question: main type (GND) (P107) for ((Q|208415}} should be person. Filceolaire (talk) 20:23, 18 May 2013 (UTC)
This is in some ways similar to an issue I've had with articles on churches (and I imagine this will occur for other organizations) which are often about buildings and the organizations housed in them. Ideally, we would have a separate item for each notable thing (building and organization). --Jfhutson (talk) 22:07, 18 May 2013 (UTC)
Yes, it a common problem. Churches and organisation is not a big problem on svwp, but schools and buildings are. Since schools easily change buildings, it's a strange habit.
But the problems that made me respond to this thread is that all Swedish municipalities changed 1970/1971. Some of them survived geographicly until 1974, when they merged with somebody else. Even if the geographic extension of the municipalities was the same 1970 as 1971, the official name and far more serious, the type of organisation, changed. I have to create items without sitelinks for the municipalities 1971-73, to be able to make a structure that describe the process. There are redirects for these (uncreated) items, but today I cannot create a relation to them. -- Lavallen (block) 05:27, 19 May 2013 (UTC)

I made a list of person pairs and will begin to move personal properties to the individuals. Byrial (talk) 09:21, 19 May 2013 (UTC)

United Federation of Planets [edit]

I don't think that United Federation of Planets should be allowed for the country of citizenship property. It is currently used in many Star Trek related items, added by User:Shisma. I believe there should be an effort to remove this as it is not a valid entry. The property should be reserved for real people with citizenship of real countries. Del♉sion23 (talk) 13:10, 18 May 2013 (UTC) There are also problems with where old citizenship law (where you have citizenship of a city) and ancient countries (such as Ancient Egypt) fit in too.. Del♉sion23 (talk) 13:31, 18 May 2013 (UTC)

I think the problem is more main type (GND) (P107) - it is organization (Q43229) and should be something like "fictional Organisation" the rest is fine, if you query fictional persons in a fictional country you should get a list of fictional inhabitants - thats fine. --FischX (talk) 13:33, 18 May 2013 (UTC)
I changed my opinion, it is completely wrong, it is not in Paris and not on Earth it is in a fictional version of Paris and the Earth that only refers to the real one. --FischX (talk) 13:42, 18 May 2013 (UTC)
I suggest you to give a look to the proposals of is fictional and truth value properties. --Paperoastro (talk) 13:46, 18 May 2013 (UTC) P.S.: also for me it is wrong mix fictional and real "things".
For me that does not sound like a good solution, should everybody who makes a Query define "is fictional" = false? (and boolean types really do not fit for Wikidata) I thought thats GND for to define the general scope? --FischX (talk) 13:56, 18 May 2013 (UTC)
Why would it be beneficial to duplicate all properties for fictional entities? Seems like a waste. Also, if we set up different entities for each "fictional France", that would prevent things like automated compiling of w:Category:Fictional French people and such. Splitting everything to separate fictional entities would make about as much sense as having "former" versions of each property, in my opinion. --Yair rand (talk) 19:31, 19 May 2013 (UTC)
Yes, progress is the increase in accuracy. Wikidata is progress, and therefore there should be accuracy (fictional, real, mathematical, virtual, etc.). But without the microscope not see any bacteria or small parts of the object. Fictional/Real=microscope. Otherwise, you can all (person, place, events and) just to name 1 ID (Object). Fractaler (talk) 12:48, 20 May 2013 (UTC)

Fictional characters notability [edit]

Are all fictional characters of notable work will be notable even if there is no dedicated article or only section exist? I think such items will be useful at least for works translated on different languages or adopted multiple times. For example, for Property:P453. Also could be included in work item as characters property to automate lists creations. --EugeneZelenko (talk) 14:00, 18 May 2013 (UTC)

I think it's pretty obvious that the answer is no but it's not clear where we want to draw the line. Some film credits list fictional characters known only as Bob, young woman, bus driver and so on. Creating a new item with the label Bob every time some film character named Bob steps in front of a camera is undesirable. (if only because it pollutes searches which is particularly problematic because of the currently awful search engine) For starters, I think we could agree that if character X has no Wikipedia article and no redirect to a Wikipedia article, then character X does not deserve an item. Pichpich (talk) 22:00, 18 May 2013 (UTC)
I think it might depend on how much info there is about the character. If a book spends a dozen pages describing a character, it might deserve an item to keep track of all that data. -- Ypnypn (talk) 03:14, 21 May 2013 (UTC)

Inheritance of taxon properties [edit]

I think that adding "phylum (P76)" and "class (P77)" to items that already have "genus (P74)" is extremely redundant and should be avoided: such items could simply inherit those properties from the genus, and so on. However, Dexbot and BotMultichill are mass-adding those properties to such items. I hereby propose to stop them from running those tasks. --Ricordisamoa 17:23, 18 May 2013 (UTC)

I suppose that these properties helps to human readability (as Wikidata is not only machine-readable database). This is because many genera has only scientific names, while "phylum (P76)" and "class (P77)" usually have common names. Infovarius (talk) 19:28, 18 May 2013 (UTC)
I don't agree. Wikidata is not strictly for humans: data can be "prettified" later, and IMHO we could have a Lua module to automatically generate taxoboxes or taxonavigations with few information on each item. --Ricordisamoa 21:06, 18 May 2013 (UTC)

I disagree because if you want to see it that way, nobody should add P107 (main type) to items which have already something that shows what is the main type (e.g. birth date or birth place). figuring out properties of an item by some other properties of that item is not our job, and besides Wikidata is not for Wikipedia exclusively, If google wants to know what is the phylum of a species, we shouldn't make them to write a very complicated code to review and load so many other pages every time to understand what is the phylum Amir (talk) 05:43, 19 May 2013 (UTC)

I've launched this RFC. --Ricordisamoa 10:56, 19 May 2013 (UTC)

Google version of wikidata [edit]

Just spotted a presentation from Google I/O about their Freebase project. This is their project to turn the information in wikipedia into a database. Some similarities to wikidata but a lot of differences too. One thing they don't seem to worry about is fact checking the wikipedia information. Filceolaire (talk) 20:08, 18 May 2013 (UTC)

w:en:Freebase. --AVRS (talk) 20:22, 18 May 2013 (UTC)
We can do much better than that. Danrok (talk) 23:28, 18 May 2013 (UTC)
They have several programmers working on the development, they have servers and ressources to handle large amount of data, they have less contraints than Wikidata (relation between wikipedia article and wikidata item),... Already now their interface is quite better. The only thing which can do the difference in favor of Wikidata is reliability through referencing. Snipre (talk) 08:58, 19 May 2013 (UTC)
Freebase is already several years old, it seems that Google took it over recently. If you believe that freebase is superior to WikiData, then change your bet ;-) WikiData is (for me at least) at first a tool to manage data we can use in the encyclopaedia, and not a goal by itself. Both can develop independently, and you'll never know where their roads may cross or merge. Edoderoo (talk) 10:53, 19 May 2013 (UTC)
First, freebase is old, of course we can learn from freebase but you can't use freebase in Wikipedia and freebase can use Wikis as a source (with wikidate even easier) but it is only about aggregation wikidata is a tool for Wikipedia, and thats makes wikidata strong - less data rott... --FischX (talk) 11:06, 19 May 2013 (UTC)
I don't find Freebases interface to be better. In fact it is quite poor, IMO. Having said that, it doesn't appear to be of Google's creation, they tend to have interfaces which are similar to what we have on wikidata. Danrok (talk) 17:36, 19 May 2013 (UTC)
To me Freebase looks like it is a just a huge bloated copy of every Amazon and online retailer page that ever existed. Most of the information is music, film and if a certain printer has a scanner. Every science item I looked at was just a poor copy of the Wikipedia infobox with no additional and easily obtainable information added. --Tobias1984 (talk) 17:46, 19 May 2013 (UTC)
Considering who payed for Wikidata, I rather suspect that Google plans on using our content eventually. Whether that will be in symphony with Freebase or in lieu of it is for them to decide. — PinkAmpers&(Je vous invite à me parler) 02:31, 24 May 2013 (UTC)

Proposal to improve on "read in another language" [edit]

Hello I would like to suggest an improvement in the section "read in another language". Many times me (or other users speaking different languages ​​all over the world) are looking to find an article in their language, and we find it in other language. When entering "read in another language" we can see a list of languages ​​that have been written the same article. I want to offer to add a form "Request this article in your language" at the bottom of that list (pic01),

pic01

there it will be possible to choose from a list of languages ​​that do not yet have that article, the requesting process is completely finished by the user in that form. So, requesting for articles ​​that exist in other languages ​​will be very intuitive and user-friendly for readers all over the world, who dont know the "normal" ways for requesting an article. after requseting the data will move to db like this: (pic02)

pic02

users will see requests like this: (pic03)

pic03

and they can go to requests page, that will contain table like the db, but somthing friendly with sorting options. what is your opinion? someone can help me technicaly do it? thank you all the users of Wikipedia! liran.--Liransha (talk) 04:57, 19 May 2013 (UTC)

New RFC: [edit]

Inheritance of taxon ranks; please comment. --Ricordisamoa 08:27, 19 May 2013 (UTC)

Allow multiple entries of the same article [edit]

I can see it is impossible to add the same article into miltiple Wikidata items. Will it be possible in the future?

Example when this is needed:

  • There is a French localized version of a computer game, and there are articles in another languages about this specific French version. The French article would have to be both in the Wikidata item connecting articles about the game in general and in the Wikidata item connecting the articles about the French version.

Real-life example:

  • Japanese article "Kawaii", which is a Japanese word for "Cute". (but not exactly, the meaning is not quite the same). There are articles in many languages about the concept of cuteness in the Japanese culture (the articles are usually titled "Kawaii"). The Japanese article is currently in the Wikidata item for "Kawaii" (Q281639), but it would also want to be in the Wikidata item for "Cuteness" (Q1183652) so that other articles about "Cuteness" linked to it.
  • Another problem. Currently, the English-language article "Cuteness" links to the Japanese article "Kawaii" using an old-fashioned interlanguage link in the article text. But recently someone on Wikidata removed the Japanese article from "Kawaii" (Q281639) and added it to "Cuteness" (Q1183652). As a result, a bot removed the interlanguage link from "Cuteness" in the English Wikipedia as "provided by Wikidata". When reverting the move, I had to undo the bot action in the English Wikipedia too. --Moscowconnection (talk) 08:32, 19 May 2013 (UTC)


To address your first sample, I think it is conceivable that there be two items: one about the game and another about the localized version. In that case, I think only the main item would have interwikis, but not the one about the localized versions. --  Docu  at 16:47, 20 May 2013 (UTC)
Actualy, it was already discussed here: #Interwiki problem!. My problem was hypothetical, I simply wanted to show why multiple entries of the same article should be allowed.
As an aside note, I think Wikidata is flawed and very inconvenient. The technical skills needed to edit Wikipedia have just risen to a new level. --Moscowconnection (talk) 17:43, 20 May 2013 (UTC)
Not as flawed as the old model for interwiki links! What a mess that was. You can always give suggestions on improvements here: Wikidata:Contact the development team. Danrok (talk) 18:01, 20 May 2013 (UTC)
See also Wikidata talk:Interwiki conflicts. It should be possible to link to redirects in the future, which hopefully will be showable in interwiki links (I haven't seen any mention of an actual implementation or plans though). --AVRS (talk) 15:15, 21 May 2013 (UTC)

Merging properties [edit]

I've developed a simple Python script to help merging properties; it can remove multiple claims at once, and I'll soon add support for sources. You can view a preview here.

What do you think? Could we use it for head of government (P46) (to be merged into head of local government (P6)) and/or sister (P9) (into brother (P7))? --Ricordisamoa 13:08, 19 May 2013 (UTC)

What's the plan exactly? Should that not be head of local government merged into head of government, and head of local government property deleted? Danrok (talk) 17:45, 19 May 2013 (UTC)
As far as brother/sister goes, it would make sense to merge into one sibling property. Danrok (talk) 17:49, 19 May 2013 (UTC)
Per WD:PFD, the general consensus is that head of government (P46) should be deleted, and head of local government (P6) should be given a more generic name. Or do you think viceversa? --Ricordisamoa 18:33, 19 May 2013 (UTC)

Wikidata Useful [edit]

Is there any possibility to use "Wikidata Useful" to add "novalue" or "somevalue" to a property? I know how to modify it, to be able to add any normal claim like 'px:qy', but I feel unsure if 'px:novalue/somevalue' is possible to do. -- Lavallen (block) 16:39, 19 May 2013 (UTC)

County of 'state' items [edit]

This was brought up earlier #Notability question, but I'd like to bring it up again to see what the clear consensus is. The item in question (in particular) is Q12037308 (county of South Dakota). The one discussed earlier was Q11774062 (county of Arkansas), but there are many more: Q13217186 (county of Arizona), Q13212489 (county of California), Q12262532 (county of Minnesota), etc. It probably would be a good idea to keep or delete them all. Should these items be kept or deleted? The Anonymouse (talk | contribs) 15:38, 20 May 2013 (UTC)

Since the definition of a County is different in each US-state: keep.
i.e. this cannot be used as reason to create items as "municipality in Norrbotten County, Sweden", since every municipality in Sweden looks the same, nomatter in which County. -- Lavallen (block) 16:35, 20 May 2013 (UTC)
List of counties in South Dakota (Q923462) is a list page. We do not use List of U.S. states (Q1682357) for US states. That said I think that it would make sense to transform the English Wikipedia articles into real articles. Actually en:List of counties in California is already more than a mere list. --Zolo (talk) 19:24, 20 May 2013 (UTC)
  • If the definition of a county in each U.S. state is different, it's so negligible that it doesn't even matter. I think we should just use Q47168, county, for counties. TCN7JM on the Road (talk) 19:39, 20 May 2013 (UTC)
  • It is absolutely not negligible. In California, counties have extensive powers, in Connecticut, they have no powers at all. --Zolo (talk) 20:11, 20 May 2013 (UTC)
  • I wasn't talking about governmental definitions, I was talking about geographical definitions. I don't really see how the amount of power counties have in each state warrants different items. Either way, why can we not just use Property:P131 to differentiate between states? TCN7JM 20:42, 20 May 2013 (UTC)
  • I think that specifying what the political/economic attributions of an administrative division is very relevant data. As it cannot be done at the federal level, that needs to be done at the state level, just as we have separate items for communes of France and communes of Italy. The main argument I see against state-specific property, is that is makes it a bit harder to generate links in the settlement_type parameter of en:Template:Infobox settlement. But this is just one instance of a major question that we need to solve in more general terms: whatever we do, we will often get values that do not have a valid Wikipedia sitelink (that not be very obvious in en.wikipedia, but it is for smaller languages). We need a more general way to handle that, probably through smarter templates. In this case, I guess it should be something like linking to the first valid sitelink encountered going up the item's subclass of (P279) chain. --Zolo (talk) 21:32, 20 May 2013 (UTC)
  • I will just agree to disagree. Since this issue only came up because I was doing stuff with South Dakota county items, what shall I do? Shall I add the "county of South Dakota" item to the county items I work with? TCN7JM 21:38, 20 May 2013 (UTC)
  • I think it would be odd for Wikidata use a system whereby a new item has to be created every time we want to answer a statement and there isn't an appropriately named item available. It would be like blue linking every word in every sentence in Wikipedia. Can there not be a way to allow for a string answer instead? The same way that some key words in infoboxes are linked but not all are? Del♉sion23 (talk) 20:13, 20 May 2013 (UTC)
  • I dont think using a sring would make any sense here. The question is not about the name (indeed it may make sense to relabel "county of California" into "county"). What matters here is that a county is not the same things in different states, and that can only be captured by an item. Suppose you want to get a list of all subdivisions of the US that have some fiscal autonomy, it should include counties of California, but not counties of Connecticut. If we want to be able to do that, we need a dedicated "county of California" item. --Zolo (talk) 20:20, 20 May 2013 (UTC)
    • I do not agree that there is a need for items for county of each US state to make such a list. You could use county (Q47168) instead combined is in the administrative unit (P131). Byrial (talk) 21:36, 20 May 2013 (UTC)
      • That is exactly what I said, and I stick by that opinion. The extra specificity is unneeded when we already have properties and items to use instead. TCN7JM 22:10, 20 May 2013 (UTC)
      • I agree with Byrial, there are ways available to complete this task without having to create loads of empty items. Del♉sion23 (talk) 22:54, 20 May 2013 (UTC)
        • The things is that the items should not be empty. "type:county, located in South Dakota" is clearly enough to guess that something is a county of South Dakota, but it does not tell us what a county of South Dakota is, and that is the job of a "county of South Dakota" item. --Zolo (talk) 06:23, 21 May 2013 (UTC)
          • The job of an item, is not to explain anything but to link an explanation in form of interwikilinks, and there is nothing to link here because it is just not significant enough to justify a Wikipedia article. If the differences of counties of US-states would be included in Wikipedia, it would be in form of a segment inside of an existing article at best. --Sixsi6ma (talk) 10:12, 21 May 2013 (UTC)
            • Uh do you really believe that "The job of an item, is not to explain anything but to link an explanation in form of interwikilinks" ? If so, you miss a good part of what Wikidata is about. --Zolo (talk) 11:34, 21 May 2013 (UTC)
          • Please tell what counties of South Dakota have in common besides being counties of South Dakota. Right now county of South Dakota (Q12037308) doesn't have any statements beyond that. If it did, it would be easier to see a need for the item. Right now I cannot see a need. Byrial (talk) 12:00, 21 May 2013 (UTC)
            • I do not know for South Dakota, so I take California :): it is governed by a "board of supervisors" (whose powers are determined by Californian law) and it has the ability to raise taxes (that is true in some other states, but to varying degrees, and it is determined by state, not federal, law). There are other specific features (see for instance wikisource:en:California Constitution/ARTICLE XI), but these one should be sufficient: that makes a county of California about as different from a county of Connecticut as two administrative subdivisions can get (conties of Connecticut have no power at all, they are just statistical units) --Zolo (talk) 14:45, 21 May 2013 (UTC)

Tech newsletter: Subscribe to receive the next editions [edit]

Latest Tech news from the Wikimedia technical community. Please inform other users about these changes.
Recent software changes
(Not all changes will affect you.)
  • The latest version of MediaWiki (version 1.22/wmf4) was added to non-Wikipedia wikis on May 13, and to the English Wikipedia (with a Wikidata software update) on May 20. It will be updated on all other Wikipedia sites on May 22. [1] [2]
  • A software update will perhaps result in temporary issues with images. Please report any problems you notice. [3]
  • MediaWiki recognizes links in twelve new schemes. Users can now link to SSH, XMPP and Bitcoin directly from wikicode. [4]
  • VisualEditor was added to all content namespaces on mediawiki.org on May 20. [5]
  • A new extension ("TemplateData") was added to all Wikipedia sites on May 20. It will allow a future version of VisualEditor to edit templates. [6]
  • New sites: Greek Wikivoyage and Venetian Wiktionary joined the Wikimedia family last week; the total number of project wikis is now 794. [7] [8]
  • The logo of 18 Wikipedias was changed to version 2.0 in a third group of updates. [9]
  • The UploadWizard on Commons now shows links to the old upload form in 55 languages (bug 33513). [10]
Future software changes
  • The next version of MediaWiki (version 1.22/wmf5) will be added to Wikimedia sites starting on May 27. [11]
  • An updated version of Notifications, with new features and fewer bugs, will be added to the English Wikipedia on May 23. [12]
  • The final version of the "single user login" (which allows people to use the same username on different Wikimedia wikis) is moved to August 2013. The software will automatically rename some usernames. [13]
  • A new discussion system for MediaWiki, called "Flow", is under development. Wikimedia designers need your help to inform other users, test the prototype and discuss the interface. [14].
  • The Wikimedia Foundation is hiring people to act as links between software developers and users for VisualEditor. [15]
Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Unsubscribe • 21:22, 20 May 2013 (UTC)
Important note: This is the first edition of the Tech News weekly summaries, which help you monitor recent software changes likely to impact you and your fellow Wikimedians.

If you want to continue to receive the next issues every week, please subscribe to the newsletter. You can subscribe your personal talk page and a community page like this one. The newsletter can be translated into your language.

You can also become a tech ambassador, help us write the next newsletter and tell us what to improve. Your feedback is greatly appreciated. guillom 21:22, 20 May 2013 (UTC)


Merging of items [edit]

I really hope someone is working on a tool to help merging of items. It is really annoying to do. I just increased my contribution counter by 42 to make one merge! And it was just links, labels and descriptions. Yesterday I had another one, where I in addition to this also moved 5 or 6 statements with sources. It can take long time, and is an error-prone process. Please, if somebody can make some sort of tool to help, please do! With annoyed regards, Byrial (talk) 21:45, 20 May 2013 (UTC)

You don't need to these edits one by one, if you have "autoEdit" gadget enabled. But I agree, that it would be really helpful to have some tool to make merging faster and easier. --Stryn (talk) 21:53, 20 May 2013 (UTC)
Thank you. I was not aware not that gadget. I will add a mention to Help:Merge. Byrial (talk) 06:57, 21 May 2013 (UTC)
Wikidata:Requests for permissions/Bot/Hazard-Bot 8 has been open for over a month now. It could help.  Hazard-SJ  ✈  01:08, 21 May 2013 (UTC)
Thank you. I will comment at the RFP/B. Byrial (talk) 06:57, 21 May 2013 (UTC)
here Ebraminio developed a simple JS Tool which needs some improvements and developments Yamaha5 (talk) 15:52, 21 May 2013 (UTC)
Yes. I really need help because I am not very familiar with Wikidata API. My script currently is supporting moving sitelinks/labels/descriptions but sometimes it will make a new item! Also its UI and functionality really needs improvement. –ebraminiotalk 23:13, 21 May 2013 (UTC)
I made a "safer" version here. --Ricordisamoa 00:09, 22 May 2013 (UTC)
Thanks! Modified and merged! –ebraminiotalk 09:56, 22 May 2013 (UTC)
merge.js now is supporting moving claims! –ebraminiotalk 14:02, 22 May 2013 (UTC)

Concerning the "Move" tool, would it be possible that it moves labels and description at the same time as the corresponding language link ? the moving of labels and description is painful, especially because you need to remove each one before adding it to the other item, in "foreign" languages (i.e. not your work language)…

Great! --Ricordisamoa 14:41, 22 May 2013 (UTC)
Also automatic request for deletion! :P –ebraminiotalk 15:20, 22 May 2013 (UTC)
Thank you for your efforts! I tried User:Ebraminio/merge.js to merge Q8522711 to Q8976320. It seems that it moved links, labels and descriptions OK, but then it continued to display "Please wait..." for minutes (and is still doing it in another browser tab). There is 2 statements, which are not moved. Byrial (talk) 16:02, 22 May 2013 (UTC)
Another test: Merge Q10188222 to Q8529546. There is no statements here. Link, label and description moved OK, but the script does not stop. Byrial (talk) 16:09, 22 May 2013 (UTC)
In the two first test, I did not select "Request deletion for this item on RfD". This time for merging Q8575603 to Q8986978 I did. It still doesn't stop after movinf items, labels and descriptions. and doesn't request deletion. Byrial (talk) 16:26, 22 May 2013 (UTC)
In my test, Request RFD is doesn't working (i was checking that)--DangSunM (talk) 16:28, 22 May 2013 (UTC)
I am hard working on it but I think now is OK on RfD. –ebraminiotalk 16:50, 22 May 2013 (UTC) (edited: –ebraminiotalk 17:01, 22 May 2013 (UTC))
Tell if you want real items to test with. I can find many which need merging. Byrial (talk) 17:09, 22 May 2013 (UTC)
It seems it is not possible to move two or more claims at once (with one edittoken) but for other items that you linked, it is working now so, of-course, thanks. –ebraminiotalk 17:41, 22 May 2013 (UTC)
I tested by merging Q8818216 with Q6454629. One claim was moved, but the source was not moved. Byrial (talk) 18:29, 22 May 2013 (UTC)
Moving references implemented but not working. I am working on it. –ebraminiotalk 19:43, 22 May 2013 (UTC)

Thank you again ebraminio and Ricordisamoa. Note that references should not be moved blindly. If an identical claim (main property and all qualifiers) is not present at the receiving item, everything including the references should be copied. But if an identical claim is present at the receiving item, all references at the obsolete item which not are at the receiving item should be added to the existing claim. Byrial (talk) 22:51, 22 May 2013 (UTC)

Good point. I think a to-do list like User talk:Ebraminio/merge.js is needed for tracking bugs and needed feature. –ebraminiotalk 07:55, 23 May 2013 (UTC)
Copied on User_talk:Ebraminio/merge.js –ebraminiotalk 11:26, 23 May 2013 (UTC)

racing, subclass of? [edit]

At the moment, racing Q878123 is a subclass of tournament Q500834. But, subclass of sport needs to be worked in somewhere, so that motorsport Q5367 comes under sport.

Any ideas on the best way to subclass these ones? Danrok (talk) 12:49, 21 May 2013 (UTC)

P131 and P17 [edit]

If I add for entity claim P131, should I also use claim P17? Or it can be received from subdivision?--Ahonc (talk) 15:03, 21 May 2013 (UTC)

You can add both now or wait for a bot to figure out P17. --  Docu  at 17:31, 21 May 2013 (UTC)
I mean that we can get country from division. For example Boyarka (Q891175) has P131 and P17, but we can get country if we have only P131 as {{#property:P17|{{#property:P131|{{#property:P131|Boyarka}}}}}} (if will be full implementation of WD in en-wiki). So claim P17 in this item is redundant.--Ahonc (talk) 22:18, 23 May 2013 (UTC)

Problem with property proposal and creation [edit]

This is mainly a personal opinion but I think we have to discuss about a more optimal way for property creation procedure.
Most of the proposals and some property creations are made without any global overview of object description. This leads to trials-and-errors process for the creation of property sets for the different items. We really need to encourage contributors to spend more time to prepare a whole and if possible complete list of properties. Snipre (talk) 18:24, 21 May 2013 (UTC)

Are you referring to any specific area of properties? I mean such as hierarchical properties, qualifiers, or something else? Danrok (talk) 23:17, 21 May 2013 (UTC)
No specific area, but all areas are concerned: see the list of properties proposed for deletion. Snipre (talk) 09:00, 22 May 2013 (UTC)
Maybe you could prepare a sample proposal to illustrate your point. Just bear in mind that only three datatypes are currently available and users will actually have to figure out how to use the properties for entry/triage/value and consistency checking/retrieval. --  Docu  at 06:16, 22 May 2013 (UTC)
Even if you don't have all datatypes, you can do a simple list of all properties you need to describe one item and don't do that on the properties proposal pages because you can't have a global overview with the current proposal template. If you want an example of mapping see chemical properties list or book properties list. When somebody wants to add proposals this kind of lists avoids redundant proposal because everything in there even common properties shered between different fields can be added.
My opinion is that few persons have a clear idea how a specific item can be described, what are the main properties which have to be proposed first and those which can be added later. People are just putting right now proposals when they have a idea, without any preparation or discussion with others contributors. In one word there is not collaboration. Snipre (talk) 09:00, 22 May 2013 (UTC)

Issues with new gadgets [edit]

Due to the ongoing issues with new gadgets (disrupting the user interface with broken JS, security issues, ...), I've now created an AbuseFilter (1) which warns admins on enabling a new gadget. It shows the the following notice: MediaWiki:Abusefilter-new-gadget. I hope you agree with this step and the action taken. - Hoo man (talk) 19:35, 21 May 2013 (UTC)

it should say familiar not firm  – The preceding unsigned comment was added by 108.170.129.173 (talk • contribs) at 21:31, 21 May 2013 (UTC).
I've slightly reworded that sentence - Hoo man (talk) 21:57, 21 May 2013 (UTC)
I hope that an administrator knows what he is doing. --β16 - (talk) 07:59, 22 May 2013 (UTC)
Why not just use an editnotice? We don't need admins showing up in the abuselog. πr2 (t • c) 01:04, 24 May 2013 (UTC)

Property proposals [edit]

Just a quick front-page reminder that there are a huge number of properties that need reviewing. More opinions will mean better refined properties: --Tobias1984 (talk) 11:45, 22 May 2013 (UTC)

Use adjacent station as a qualifier? (railways) [edit]

Please, take a look at my comment here Property talk:P81, and see what you think about this. How should it work? Danrok (talk) 15:49, 22 May 2013 (UTC)

Why Special:Preferences#mw-prefsection-gadgets dosen't working? [edit]

Tracked in Bugzilla (?)
Bug 48693

I tried to using new tool, so I tried to check and saving the setting, but it doesn't work now. What happened?--DangSunM (talk) 16:04, 22 May 2013 (UTC)

Try to refresh/purge the browser/server's cache. --Ricordisamoa 18:30, 22 May 2013 (UTC)
Never mind, Now It is clearly saved. cheers.--DangSunM (talk) 19:49, 22 May 2013 (UTC)

Finally! [edit]

I forked Ebraminio's merge.js and now it can even delete items, with a simple checkbox! See the log.

The code: User:Ricordisamoa/merge.js. --Ricordisamoa 18:25, 22 May 2013 (UTC)

I merged that again! :P –ebraminiotalk 18:55, 22 May 2013 (UTC)


Now it can work in a slightly different way:

  • click the "Merge it with..." portlet-link;
  • now visit with your browser the other item (in case, refresh the page):
  • a "process merge" button should appear next to the "Read" tab; click on it:
  • the "id" field should be pre-filled;
  • you can optionally auto-RfD the item, or directly delete it if you're sysop;
  • click "Merge"! --Ricordisamoa 19:26, 22 May 2013 (UTC)
P.S. now it always moves content to the item with lower Qid. --Ricordisamoa 19:51, 22 May 2013 (UTC)
Can you commit your changes on top revision of User:Ebraminio/merge.js? I don't think a fork would be useful. You are very welcome on editing original code anyway. –ebraminiotalk 19:52, 22 May 2013 (UTC)
P.S. it is very good changes, thanks 19:53, 22 May 2013 (UTC)

Nice job Ebraminio and Ricordisamoa. Deleted from tool is working clearly. But It takes long time to move cliams. In my opinion.

If you guys agree that, I will Add to gardget.

comment about p.s we can add that warning in the tool

cheers, --DangSunM (talk) 19:54, 22 May 2013 (UTC)

Would be nice not to autowatch pages which were successfully merged and subsequently deleted. Not sure if that's possible or not, since it appears that we are actually editing each page. --Izno (talk) 00:49, 23 May 2013 (UTC)
Alternatively to the above, you could stop redirecting us to the merged into page from the merged page. --Izno (talk) 02:23, 23 May 2013 (UTC)
My Firefox v20 on Windows 7 64 bit was choking on a fair number of moves. It was somewhat intermittent, but seemed roughly correlated to whether there were claims that were strings. Can you look into that?
Second feature change: Possibly, multiple item merging? Could do something like a comma separated input. --Izno (talk) 02:23, 23 May 2013 (UTC)
Multiple item merging was goal of merge of from the beginning of development and all of its base functions is supporting it but it is not supported through the UI. I am a but busy till Monday (I must prepare my self for an exam :P) but I think Ricordisamoa can implement it simply by the way that you suggested or a more superior way (using multiple Wikidata entityselector). –ebraminiotalk 07:49, 23 May 2013 (UTC)
Added on User talk:Ebraminio/merge.js –ebraminiotalk 11:28, 23 May 2013 (UTC)

Thanks very much for this, it looks like it will be very useful! :D Del♉sion23 (talk) 22:24, 23 May 2013 (UTC)

StreamDelete is live [edit]

StreamDelete is a new-concept RfD system, especially designed for duplicate/merged items.

You can now nominate an item by using either the StreamDelete official client, or User:Ricordisamoa/merge.js (derived from User:Ebraminio/merge.js).

The example on the page is live: feel free to delete the suggested item!

Features
  • colored number of sitelinks/claims/labels/descriptions/aliases in the item (using Module:WBHacks)
  • label for all items
  • practical grouped-rows GUI, stylish buttons
Todo
  • working "merge" button (using merge.js)
  • quick "delete" popup, no need to open new tab or reload the current one
  • automatic removal of deleted items
  • suggestion on "what item to merge into"

Please comment below. --Ricordisamoa 21:22, 22 May 2013 (UTC)

Data inclusion by labels is now available on Wikipedias and time datatype is getting closer [edit]

Heya folks :)

I just wanted to let you know that it is now possible to include data from Wikidata using the property's label (not just the ID). So in essence this means that you can for example use {{#property:continent}} instead of {{#property:P30}} if you don't want to remember the ID there. Both of these would return "Europe" if used in the article about Spain for example.

In related good news: The time datatype has progressed very well and we expect to be able to deploy it next week. However it'd be awesome if you could help test it on the demo system to make sure we have not missed any major issues. Help with translations on translatewiki.net would also be most excellent.

--Lydia Pintscher (WMDE) (talk) 21:58, 22 May 2013 (UTC)

The time datatype looks great. A few issues, though:
  • The demo doesn't seem to have a way to go more specific than one day. Is this planned for a later version, or a separate datatype, or not at all? (Or have I just not figured out how to use it?)
  • The demo allows for dates that didn't actually exist (ie February 30). Is this deliberate? If so, I'm not sure it's a good idea.
  • Which calendar was used to input the data is stored, apparently. While this makes some sense for calendars that don't match up perfectly with the Gregorian calendar, I don't see why it's needed for calendars like the Julian calendar.
  • The "Precision" dropdown is very buggy.
--Yair rand (talk) 22:38, 22 May 2013 (UTC)
Good news! In French, there is a display issue for the time datatype: it shows "février 15, 1900" while it should be "15 février 1900". Ayack (talk) 07:38, 23 May 2013 (UTC)
There is an similar problem to the french one in Icelandic too, as the date should be shown in the format: "day. month year". So, the dates on Q4 in the demo repo should be 31. febrúar 1900 and 9. mars 1814, respectively.--Snaevar (talk) 11:35, 23 May 2013 (UTC)
I do not care very much that the same problem is also in Swedish. It looks like this:
      <claims>
        <property id="p16">
          <claim id="q4$1667793b-4b34-f318-a6b9-4fc122deec5e" type="statement" rank="normal">
            <mainsnak snaktype="value" property="p16">
              <datavalue type="time">
                <value time="+00000002000-01-01T00:00:00Z" timezone="0" before="0" after="0" precision="0" calendarmodel="http://www.wikidata.org/entity/Q1985727" />
              </datavalue>
            </mainsnak>
            <qualifiers />
          </claim>
          <claim id="q4$b57d4ed3-46d9-a2c5-3bc0-b7e8a96ccd88" type="statement" rank="normal">
            <mainsnak snaktype="value" property="p16">
              <datavalue type="time">
                <value time="+00000001967-04-24T00:00:00Z" timezone="0" before="0" after="0" precision="11" calendarmodel="http://www.wikidata.org/entity/Q1985727" />
              </datavalue>
            </mainsnak>
            <qualifiers />
          </claim>
        </property>
      </claims>
in the database. That is more intresting for the use of this datatype.
What does "timezone", "before", "after" and "precision=11" stand for? -- Lavallen (block) 12:15, 23 May 2013 (UTC)
There's problem with the Finnish date also. "huhtikuu 24, 1967" (April 24, 1967) should be "24. huhtikuuta 1967". Notice -ta ending after every month. --Stryn (talk) 12:46, 23 May 2013 (UTC)

Hey :) Thanks for the feedback. Here's the replies:

  • More specific than day is planned but not implemented yet.
  • Days that don't exist are recalculated and matched with the existing date. That's the best we could come up with for now.
  • Calendar system needs to be saved because we need to know which system it was saved in and which one it is supposed to be shown in. More systems will be supported in the future.
  • Buggy precision dropdown is being worked on.
  • Incorrect display of dates in differente languages is being worked on.
  • "timezone" stands for the timezone (useful later when we can enter hours for example),
  • "before" and "after" will later be used to allow entering a range
  • "precision" corresponds to month, year, decade and so on

Thanks for testing! --Lydia Pintscher (WMDE) (talk) 12:59, 23 May 2013 (UTC)

February 30 (Q37096), existed in the Swedish calendar 1712. :) -- Lavallen (block) 13:10, 23 May 2013 (UTC)
I just tested and I can enter that :) It seems changing the date isn't actually done yet. We'll keep this in mind. Thanks! --Lydia Pintscher (WMDE) (talk) 13:16, 23 May 2013 (UTC)
Do you have any idea of how long time it will take until this datatype can be used as a "range"? That sounds to me like a much more interesting option than using both "from" and "until"-properties. And will there be any option to have an "open end" for such things as "John Doe" king of "Farfaraway" 2001-
?-- Lavallen (block) 13:32, 23 May 2013 (UTC)
As far as I understand it it is not supposed to be used as a range but rather to say that a specific date is inside a range but we don't know the exact date. I will try to clarify this though. (Might take a few days because of the hackathon in Amsterdam.) --Lydia Pintscher (WMDE) (talk) 14:06, 23 May 2013 (UTC)
If you enter "January 4" the system understands it as the month January of the year 4 CE. This is not at all what most users would expect. Could the display make it clearer, perhaps by displaying it as "January, 4" or even "January, 4 CE"? -- Ypnypn (talk) 14:35, 23 May 2013 (UTC)
In fact, even "4 January" treats 4 as the year. -- Ypnypn (talk) 14:38, 23 May 2013 (UTC)
Do you plan to support other calendar than the Julian and Gregorian? how about Era based date like for example japanese era calendar? --Napoleon.tan (talk) 16:48, 23 May 2013 (UTC)

For Ukrainian and Russian languages displaying is wrong too (should be 24 квітня 1967 and 24 апреля 1967 instead of квітень 24, 1967 and апрель 24, 1967).--Ahonc (talk) 22:28, 23 May 2013 (UTC)

First of all, yay! Secondly, I can't say I love the superscripts for "Gregorian"/"Julian". Could we just use parentheses or brackets (or perhaps even a separate column)? — PinkAmpers&(Je vous invite à me parler) 02:35, 24 May 2013 (UTC)

Issue with the implementation of the review score property [edit]

You're going to want to click and view the larger version at Commons...

Hey everyone. If you work with properties, please take a look at the image on the right. Below the black line that cuts it (kind of) in half, several different reviewers' scores are all listed together as qualifier of the same value (8.5/10) because all of the different reviews scored the game the same. This is really problematic, and I think that we need to nip it in the bud as quick as we can, because what is actually going on there is that three separate data points are getting mushed together, costing accuracy for the sake of speed of entry. With the three reviews sharing the same value, adding in the platform qualifier becomes difficult (how do you know which review it applies to?), and other possible future qualifiers, such as the name of the reviewer (most review sites have several), would also be difficult to add in.

What needs to be done is that anytime (for any property) that two different sources give the same value, they are listed as two separate values, which you can see in the circled portion of the top half of the image to the right.

Please let's not get into destructive bad habits. It happens to be that in this case it's going on in the review scores property, but it could happen on any number of others. Let's keep our data clean and useful. Thanks a bunch! Sven Manguard Wha? 06:27, 23 May 2013 (UTC)

Pictogram voting comment.svg Comment I am not sure that "What needs to be done is that anytime (for any property) that two different sources give the same value, they are listed as two separate values", at least the requires further thought and discussion. Note that the software is designed to allow several sources by statements (and several statements within each of these sources). In your example, we need separate statements not because the sources are different, but because the real meaning is (or equivalently, because the should have different qualifiers). I am not sure that it has any necessary connection to the number of source. The same source can compile several critical reviews, and conversely the same review can be provided at several different places. - Zolo (talk) 07:33, 23 May 2013 (UTC)

I think I've made something stupid. [edit]

I'm sorry to bother this page with my troubles; but I found no "help desk" kind of page.

This is the first time I tried to add a link to a particular newly created page to an existing item in what I felt was the most natural way; i. e., I located the appropriate item on d:, and tried to add the information about the new iw-sister directly on that page. This was frustrated. I'm afraid I have corrupted the underlying source text in some way in my attempts; vide infra.

The item is Q9727604; it already contains 14 iw-sisters; I tried to add fo:Bólkur:Jóturdýr. (You can follow my frustrated attempts in the item history.) Finally, i did succeed to add something somewhere in connection with the list (I think), but it is invisible.

I gave up, and tried another approach; going back to the category page on fowp, I clicked the Add links alternative. It turned out that there was no way to enter the fact that the link to the page was to be added to item Q9727604 directly. On the other hand, I had found the page by means of one of the older sister articles, and remembered that, and could enter its name and language. Your decoder told me that an item already existed for that item (namely Q9727604; big news), and asked if I really wanted to add the link anyhow. I confirmed.

The decoder dialogue reported "an unexpected error". I tried a number of times, with the same result. My suspicion is that the text string I succeeded to enter (in my second edit; see the item history) still is around in that page, but in an inappropriate manner, and that the hidden source page thus is ill-formatted from the point of view of the dialogue decoder.

As I said, I'm sorry for the trouble I've caused. Probably, someone with the right to "look behind the scene" needs to fix this, directly in the source file. Possibly, there should also be a warning somewhere visible for people like me, who believe ourselves to be experienced enough to do what we always do; i. e., to first collect all relevant information, and then to go to the appropriate place for to add it there. If there really is no way to add the links of a new page from within d: itself, there should be a clear warning about this, I think. JoergenB (talk) 14:37, 23 May 2013 (UTC)

Not sure I can understand the problem. I have just added the item fo:Bólkur:Jóturdýr to the list of interwikis on Category:Ruminantia (Q9727604). Is that what what you want? Danrok (talk) 15:25, 23 May 2013 (UTC)

Dynasties and Royal houses [edit]

What would be the best property for claiming the house to which a person belongs?

For example, Anne, Princess Royal (Q151754) = House of Windsor (Q81589). Use part of (P361), or member of (P463), or something else? Danrok (talk) 17:28, 23 May 2013 (UTC)

My advise would be member of (P463) if and only if they have Appanage (Q617593) or in any other way show that they are a part of the Royal house. Just being related to them would not be enough to be a member in my opinion. -- Lavallen (block) 17:43, 23 May 2013 (UTC)
There is already noble family (P53). Ayack (talk) 18:04, 23 May 2013 (UTC)
Good call with P53. Perhaps that would be the more appropriate one. Ajraddatz (Talk) 20:03, 23 May 2013 (UTC)
Thanks, overlooked that. Danrok (talk) 21:35, 23 May 2013 (UTC)
Retrieved from "http://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=45733074"