Wikidata:Project chat/Archive/2014/02

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


Cactaceae (Q14560) as showcase item ? P31 as a qualifier ?

The current version of the first claim of this item uses instance of (P31) as a qualifier. I'm not aware of a discussion where we discussed that or even discussed what it means ... It's not defined, hence ambiguous. What's the point of making formal statement if we don't know what they even could mean ? And can we really show that as an example ? Looks like bad practice to me. TomT0m (talk) 18:02, 25 January 2014 (UTC)

Looking at it, I understand it as the taxon name for this entity being a nomen conservandum, i.e. it further qualifies the claim "the taxon name of this is Cactaceae", or differently, "the taxon name of this entity is Cactaceae and this is a nomen conservandum". How else would you formalize this? How else could it be understood, i.e. since you say it is ambiguous, what else could it mean? --Denny (talk) 00:19, 28 January 2014 (UTC)
It's ambiguous because we did never discussed the meaning, and there is several one. For start, a qualifer can be a way to implement a reification pattern, and qualify te statement as an entity, or to implement nary relations (this has been discussed on wikdata somewhere else). So of what is this a conserved name ? the subject, the object, the statement ? We can know this only with domain knowledge until this has been discussed as a practice. TomT0m (talk) 11:34, 28 January 2014 (UTC)
Discussing is a human task, and this means we can only achieve better understanding for humans, not for machines anyway. And looking at the discussion, and again at the actual statement in question, I still fail to see any other reasonable interpretation that would make this ambiguous. As far as the formal semantics are concerned, they remain well-defined. --Denny (talk) 19:49, 28 January 2014 (UTC)
As far as the formal semantics are concerned, they remain well-defined As far as I know, instance of (P31) usage is defined in Help:Basic membership properties, in a spirit very similar to OWL or RDF. If we apply it as a qualifier, what's the meaning ? My gut feeling is that it could be used to note the membership of a statement class. Here it is used to note that the scientific name is a member of a specfic kind of normalized name (a subclbss of scientific names. i'm not saying it's a bad thing, but maybe we should think and talk a little bit more about this before showing this as an example of good practice. For example here maybe a property specific to this ind of name, I know that Filceolaire had proposed a specificaly property. Maybe Emw has a thought about this ? TomT0m (talk) 20:13, 28 January 2014 (UTC)
When I refer to the formal semantics, I mean what is specified here. Anything else is community agreement, and not part of the formal semantics (which are simply much, much weaker than the community agreement). In particular, P31 is just a normal property - it does not have the semantics of rdf:type. It is very much welcomed and indeed part of the architecture of Wikidata that communiy agreement extends the formal semantics, and possibly, one day, the software could be extended as well. But with regards to the software for now, P31 is just a normal property like any other else. --Denny (talk) 20:23, 29 January 2014 (UTC)
Denny, the community can extend the formal semantics codified in Wikibase with formal semantics of their own. The mapping of P31 to rdf:type is such a case. It was agreed to in March 2013, is noted in the property documentation, has been reviewed by an editor of the OWL 2 W3C recommendation, and was a major premise of the community's decision to delete P107 and migrate over 4 million claims.
The draft RDF export specification you reference notes 'instanceOfSnak' and 'subclassOfSnak'. To my understanding, those features have not been implemented in Wikibase due to lack of resources. instance of (P31) and subclass of (P279) provide a formal, albeit not yet baked-into-the-software, way to represent those features as the basic Semantic Web properties rdf:type and rdfs:subClassOf. For the purposes of an RDF export of Wikidata, one should be able to substitute rdf:type for P31 and rdfs:subClassOf for P279, e.g. by doing something like Markus does in, with some modifications and enhancements.
Proposed enhancements to the property documentation would provide a similar formal semantics for the community to incorporate more W3C vocabulary into Wikidata. I see these things as a significant benefit for those interested in making Wikidata more interoperable with the rest of the Semantic Web. Emw (talk) 02:21, 30 January 2014 (UTC)
It seems we have a different understanding of the term 'formal semantics'. I am speaking about how the software understands and handles the semantics and furthermore about how it is exported to a standard like OWL. If it is OK and welcome for the community to agree that P31 and P279 are proxies for rdf:type and rdfs:subClassOf, but as long as these are not actually implemented in any way - neither in the behavior of the software nor in the export - the formal semantics of Wikidata and its export do not change. E.g. qualifiers on type or subClassOf do not have a well-defined formal semantics (as far as I know), which would be a requirement to make this change in the formal semantics. This is why I stay with my statement: the formal semantics of Wikidata are not changed, and P31 and P279 are just normal properties with regards to the software and its formal semantics. But as said, we might have a different understanding of the term, and that is fine. --Denny (talk) 18:33, 30 January 2014 (UTC)
Denny, it makes sense to me that rdf:type and rdfs:subClassOf would not be valid subjects for qualifiers, since they are part of the built-in vocabulary. I don't see why that should be block type and subClassOf from being included in the RDF export specification. Qualifiers on 'instance of' and 'subclass of' could be prohibited, or, even simpler, ignored in the export.
The issue with qualifiers in 'instance of' and 'subclass of' will also apply to statements on properties, which are defined as a development goal for 2014. For example, users have said they'd like to incorporate rdfs:domain and rdfs:range into properties. Those properties (of properties) are part of the built-in vocabulary, so making statements about them would make Wikidata undecidable, and have not well defined formal semantics. So it seems Wikidata will support properties mapped to rdfs:domain etc. which cannot have qualifiers. Given that, it seems reasonable to also support rdf:type and rdfs:subClassOf, and also not support qualifiers on them. Having those fundamental RDF, RDFS and OWL properties without qualifiers in an RDF export seems drastically more useful than having them with qualifiers, but not in their standard W3C-defined form. Emw (talk) 06:36, 1 February 2014 (UTC)
Denny, I would formalize it with a new property 'nomen conservandum', which would be a subproperty of the 'taxon name' property. In other words, instead of the current statement:
taxon name: Cactaceae
taxon author: Antoine Laurent de Jussieu
date of scientific description: 1789
instance of: nomen conservandum
I would structure the statement as:
nomen conservandum: Cactaceae
taxon author: Antoine Laurent de Jussieu
date of scientific description: 1789
This would also change the 'taxon author' and 'date of scientific description' claims from being qualifiers to being first-class properties. This is in large part because queries will not handle qualifiers in the foreseeable future. So if a user wants to know which taxa were named by Jussieu, or scientifically described in the 18th century -- both of which seem like foreseeable use cases, as far as taxa go -- then that information will need to exist as a property value in the ground triple and not as a qualifier value.
I would also say that having instance of (P31) in qualifiers does seem ambiguous, though obviously most humans get the gist. P31 is rdf:type. So serializing statements with qualifiers that use P31 seems like it would require something that is not valid in OWL 2 DL: punning with the built-in vocabulary. To my understanding, doing so would make Wikidata undecidable and thus forfeit an essential property of querying and inference. Subproperties -- which are valid and well-supported as rdfs:subPropertyOf in OWL 2 DL and SPARQL (and Semantic MediaWiki!, as you know) -- seem like a much better way to state that Cactaceae is not only a 'taxon name', but specifically a 'nomen conservandum'. Emw (talk) 00:56, 29 January 2014 (UTC)
I can't claim to really understand this "subproperty of", except that it does not exist in Wikidata yet. At the moment it is a matter of making bricks without straw, and the argument is what strawless bricks would be best.
        Having a property "conserved name" as such would be awkward; it suggests that every taxon has a conserved name, while in reality the vast majority of taxa don't have a conserved name, and of those that do have a conserved name, some have more than one. Being conserved (or not) is an attribute of a scientific name, not of a taxon.
        Similarly, date of scientific description and taxon author are attributes of a scientific name, not of a taxon. The year of taxon name publication (P574) is the date of formal publication of the scientific name; while the date of first scientific description of the taxon may be years (decades, centuries) earlier than that. The taxon author (P405) is the person(s) credited with the formal publication of the scientific name; there often is another person(s) who defined the taxon.
        I am not particularly happy with the structure in the proposed showcase, but it is better than any other existing option. - Brya (talk) 04:05, 29 January 2014 (UTC)

Brya aren't name and date more attributes of a description ? TomT0m (talk) 12:27, 29 January 2014 (UTC)
I don't follow; descriptions don't come into it. - Brya (talk) 17:22, 29 January 2014 (UTC)

??? This "conserved name" is tightly defined. What is not defined is "taxon name". - Brya (talk) 17:36, 28 January 2014 (UTC)

Reading the Wikipedia article, it looks like it's well defined. But it's not really what I'm talking about here, which is more related to how we express it in Wikidata. TomT0m (talk) 18:03, 28 January 2014 (UTC)
Newsflash: this is Wikidata, a place where we only gather material that is defined elsewhere. How 'we' define things here does not matter, for the stuff we define ourselves has no place here. - Brya (talk) 18:23, 28 January 2014 (UTC)
i'll politely invite you to read my answer again. I said express, not define. TomT0m (talk) 18:30, 28 January 2014 (UTC)
Specifically has been proposed as a replacement property, instead of using P31 as a qualifier. It was proposed by Micru, not by me but thank you for the name check TomT0m. It is in need of a few more supporters I think. Filceolaire (talk) 21:31, 28 January 2014 (UTC)
I agree with TomT0m that the current definition is not right. It looks like what it is trying to do is the equivalent of this literal reification scheme, an example of which is depicted here. So, I think that a qualifier is the right way to go, but it should not be instance of (P31). It should be some other property, which would be analogous to datacite:usesIdentifierScheme (more about which here, if anyone is interested). "specifically" would be better, but not quite right. What this qualifier is attempting to do is identify what vocabulary the literal value is a part of. Klortho (talk) 03:11, 29 January 2014 (UTC)
Each taxon has one or more scientific names (P225). For example, a taxon can have different scientific names if it was moved to another genus which happens to many taxa or if two authors describe the same taxon not knowing of each other which also happens frequently. Therefore, each scientific name (!) has one or more authors and a year of description. Thus, these are properties of the scientific name and not of the taxon itself. Using qualifiers for this information is correct, adding it directly as statements to the taxon itself is infeasible as in many cases you could not tell to which name an author corresponds. Now, in rare cases, this specific taxon name is of a specific type. You can ignore this piece of information and use the taxon name as given. But nonetheless this information is interesting (and thus we want to store it) as it for example says why a newer description takes precedence over an older description which is not the default. And what is the property to set the type of something? if you are unsure, have a look at the recent Requests for Property Deletions It is: instance of (P31). Thus, it is used in Cactaceae. Perfect. Done.
Now the questions arises, how to transform this model to RDF. There are two problems: 1) RDF does not support qualifiers at all and 2) P31 resembles a special property in RDF (it is, however, not very special in Wikidata) and it is, thus, extremely unclear how to export this special property to RDF when it is used as qualifier. The simple answer to this is: I do not care. I model data in Wikidata to be used in Wikipedias/-voyages/-commons/..., not in RDF. The complex answer is: As long as we do not have even a simple RDF export at all it is just time killing to discuss rare exceptions. If you care nonetheless: Ignore everything what does not fit in the RDF world (e.g. qualifiers or P31 as qualifier), you won't loose too much information. If we later have an RDF exporter, which copes somehow with P31<->RDF:subclass_of as well as with qualifiers, then we will also easily find a way to cope with P31 as qualifier. If not, I will help you, I promise. Till then, let the data we need to model for Wiki(pedias|...) be modeled as simple as possible for our users in the Wiki world. Thank you.  — Felix Reimann (talk) 15:42, 29 January 2014 (UTC)
At that point it will be late to touch anything, as all the ecosystem will be built. The more it will be used, the harder it will be. On the other hand thinking a few minutes now the database is building and the datas not used much is at very low cost. TomT0m (talk) 22:19, 29 January 2014 (UTC)
Mind to read Dennys remark? --Succu (talk) 22:45, 29 January 2014 (UTC)
Yeah I did, It's nothing new and I'm in plain spirit of the message : seeking community agreement, Succu. TomT0m (talk) 09:42, 30 January 2014 (UTC)
Felix Reimann, I was with you up until, "Thus, it is used in Cactaceae. Perfect. Done.". The problem is that, the way you are suggesting using it, instance of (P31) would apply to the literal data value "Cactaceae"; whereas, qualifiers apply to, and modify, the statement. That is where the confusion lies, I think. I think it would be better to have a more specific qualifier property, explicitly for this case. Something like "uses scheme". But, of course, we could, as a community, just come to the consensus that when instance of (P31) is used as a qualifier, that's what it means -- but it seems too messy and ambiguous to me, to overload it in this way. Regarding caring (or not) about RDF, I will mention why I care. It's because RDF modeling attempts to be rigorous, and that this is data after all, and we should be doing our utmost to make sure that it is machine-readable and machine-processable. If data are messy, it makes it very hard to process with machines. And I agree with TomT0m, that it's better to get things right in the first place, than try to clean them up later. Klortho (talk) 04:41, 30 January 2014 (UTC)


Qualifiers do not apply to the statement, they are part of the statement. Please read carefully the mapping of Wikidata to RDF. There is a subtle, but important difference here, especially in light of a non-monotonic expression language like RDF and OWL. Sorry to be a nitpicker. --Denny (talk) 18:33, 30 January 2014 (UTC)
I'd stand by the gist of what I said, if not the letter. The way it was/is being proposed to be used, instance of (P31) would apply to the literal data value "Cactaceae". Specifically, "Cactaceae" is an "instance of" "nomen conservandum", which, IMO, is just wrong. I reread the RDF spec, and where I got my original conception from was the Berlin-population example, where the "statement node" Berlin:Statement1 is the subject of all of the qualifier triples. Perhaps I was misled by the label, and the "statement node" is really an abstract thing, but the important point is that, in no case does a qualifier property take the object of some other property as its subject. Finally, I looked up "non-monotonic", and I'm not sure you are using it right. RDF Semantics says, explicitly, "This is why RDF is designed to be monotonic". Anyways, I don't mind nitpicking, and I'm keen to understand this mapping better, and to get involved if I can, so no worries! Klortho (talk) 06:53, 31 January 2014 (UTC)
Yes, sorry, I meant monotonic. Don't know why I negated. Regarding the statement node - yes, it is an abstract thing. And thus it is very much something that can be an instance. All qualifiers apply to the statement node, never to the object or the subject. That's in spirit of a reified statement - the actual 'ground' statement is not asserted. I hope it makes sense... --Denny (talk) 00:38, 1 February 2014 (UTC)

I think there are two problems intermixed:

  1. Is it appropriate to use instance of (P31) as an ad hoc qualifier when no specific qualifier/property is available?
  2. Could we express the information in this special case in a better way?

My answer to both questions is: Yes. So I made a new proposal. --Succu (talk) 12:47, 30 January 2014 (UTC)

Name of person

I have a big problem with the wikidata concept for persons: I am adding references and for each author I have to create an item, Ok, but my problem is about given name and surname, both concepts are described by an item datatype property, family name (P734) and given name (P735). This means I have to create often a new element for the surname, and when I don't know the full list of given names, I can't add the shorten version of the given name.

For example, the item Tyler B. Coplen (Q15699424): I had to create the surname Coplen (Q15699534) and I can't add the second given name B. because I don't know it. Do we really need to have an item datatype property for this kind of data ? A string datatype property would be more easier to handle when considering the number of given names and surname and the shorten given names. I just want to be sure that this data structure is known and accepted by the community because I have the feeling that only few persons deal with references and their countless and obscure authors.

So if we really want to keep this structure, we have to create at least 24 new items, one for each letter of alphabet with a dot in order to be able to provide as much informations we can and in order to be able to build the reference templates in wikipedia whih often handle given names and surname as two different kind of data. Snipre (talk) 12:42, 1 February 2014 (UTC)

Lol, I think the datatype does not really make sense here although it allows some interesting queries with names. However, as not every name is notable for Wikidata we should change the datatype -> create a new property for this purpose as Snipre already pointed out. However, I don't know what the original intention was to set the datatype to item. -- Bene* talk 12:54, 1 February 2014 (UTC)
Doing some query according to a defined name is not constrained by the datatype of the property: we can do the same query with string as with item, this just a developement point. The problem is more about the number of given names and surnames around the world and the fictional worlds and to think if we really want to add hundreds of thousands (or perhaps millions) of item without any other information than the "instance of" the items. For famous surnames and some given names, we have some history but I don't think this covers the majority of names. Snipre (talk) 13:20, 1 February 2014 (UTC)
not every name is notable for Wikidata, Bene* they are notable as long as they are needed to make a statement so the barrier it's pretty week. If this model is maintained I would not oppose to mass name databses imports (comparing to multilingual text solution proposed below it seems better to create an item an translate only once for all uses of the name). TomT0m (talk) 16:46, 1 February 2014 (UTC)
Or perhaps we have to think about a dual use of properties: create two properties for surname and given name (and why not for author), an item data type and a string data type property, and define the rule that a given name, or a surname ( or an author) can have an item in wikidata if it is used at least X times in other items (X>1). Then using a maintenance analysis we will analyze the frequency of the different surnames, given names (and authors) defined in the string datatype property and when the limit is reached we will create the corresponding item and perform the analysis task to see if the different name uses are an unique person or several persons before the replacement. We eally need to think about the fact that adding references according to the currant scheme implies the creation of different other items. If a reference about a scientific article contains 5-10 authors, creating an item for it implies 5-10 items for the different authors (the probability to reuse an author item for different reference is low) and perhaps 1-5 other items (20 potential names (30 if we considered second given names), but most of names are common and it can be expected to find them in wikidata) for the given names or surnames. So for one reference added something like 16 items created Snipre (talk) 13:36, 1 February 2014 (UTC)
I don't really know why these properties were created with the item datatype. Per the property proposal discussions of family name (P734) and given name (P735), there were oppositions to the datatype. I would oppose to using strings as the datatype, as it implies that names are not language-dependent. I think the best datatype to use is the MultilingualTextValue datatype. This solves the translation problem raised in the RfC and can show how the name is translated in different languages. --Wylve (talk) 14:06, 1 February 2014 (UTC)
Ok, that makes sense. However there should be a "main" value for the MultilingualTextValue datatype so that other languages still get a value if it only exists eg in en. But this is something that can be done in future. Atm I think it isn't a solution to use the TextValue as Wylve pointed out. However, I'd also oppose to create an item for every name because this 1) doesn't support language fallbacks and 2) creates a huge mass of items including the most exotic names that would otherwise be never notable. 3) this still does not solve the "B." problem. -- Bene* talk 16:57, 1 February 2014 (UTC)
That multilingual text would support language fallbacks but not item labels would be a mistake at leaàst, if not a bug. using multilingual values for names used a lot would imply a lot of duplication of datas and translation to do and redo and redo again while only once with an item. Item is better. TomT0m (talk) 17:31, 1 February 2014 (UTC)
Hmm, that's of course a good argument that items only have to be translated once. Just a question, are there some names that are translated differently to some language while being the same in en? Then we have to decide carefully which item to choose. Also I am not sure if we should translate all names because a name is something personal and a person has only one name. For example en:George Frideric Handel's original name is Georg Friedrich Händel, so how can we say that his name is George Frideric Handel while he was never called so? -- Bene* talk 19:56, 1 February 2014 (UTC)
Do some names are translated differently? All names if you look at non Latin alphabets^^ There are different rules for transcribing (phonetic vs orthographic). We'll have to use the AKA field and still will produce a lot of funny results. --Kolja21 (talk) 03:12, 2 February 2014 (UTC)
Using items wouldn't work for Chinese names at least, as the same character can have different romanization (e.g. Jet Li (Q159577) uses "Li", while Bruce Lee (Q16397) uses "Lee" despite the fact that their family name is the same character). Forcing incorrect romanization onto names will cause inaccuracies and confusion. --Wylve (talk) 06:05, 2 February 2014 (UTC)
Same problem in all languages. Take for example Pyotr Ilyich Tchaikovsky (Q7315) with the common transcriptions "Tschaikowski", "Tchaikovsky", "Čajkovskij" and "Chaikovski". And thats just the start. It gets real crazy, when someone translate a name back into the original language, what happens quite often if the person is not famous. As a child's game it's called Chinese whispers (Q151939). That's why authority control is so important for libraries. --Kolja21 (talk) 06:28, 2 February 2014 (UTC)
Not only there ara many names that are translated differently to some language while being the same in en, there are also many names that are translated differently to en while being the same in some language. As an example you can look for the name יהודה, which is translated as Judah for Judah Leon Magnes (Q1710862) (and many others...), as Yehuda for Yehuda Meir Abramowicz (Q2778213) (and many others...) and as Yehudah for Yehudah L. Werner (Q96311) (and many others...) Should we create three WD items "יהודה translated as Judah into English", "יהודה translated as Yehuda into English" and "יהודה translated as Yehudah into English"? I sincerely hope we shouldn't; if so, we should do the same for all other languages too...--Shlomo (talk) 14:07, 2 February 2014 (UTC)
If a person named "Yehuda" never actually went by "Judah", then we don't need a statement saying "Judah" was his name. --Yair rand (talk) 21:45, 2 February 2014 (UTC)
That's right, but we may need a statement saying "יהודה" was his name in Hebrew. Will the person named "Yehuda" in English context and "יהודה" in Hebrew context share the same name item with the person named "Judah" in English context and and "יהודה" in Hebrew context? If so, then the users (Wikipedias) can't retrieve the person's English name from an item-based statement. If not, we have to convince the Hebrew editors, that the name "יהודה" (of the first person) is not the same as the name "יהודה" (of the other person) and needs another item. And we will have to create a really HUGE amount of items for every possible combination of name variants in various languages, since there are also other languages than just English and Hebrew...--Shlomo (talk) 22:55, 2 February 2014 (UTC)
If the person actually goes by a different name on different occasions, then they should have a statement for that. If they don't, then they shouldn't. If Hebrew-speakers prefer to grab the closest Hebrew equivalent/ancestor name for "ג׳ודה" when referring to such a person, that's a very different situation than it actually being the person's name. There are actually situations where multiple names will go under the same spelling in some languages (there will probably be multiple name items labelled "Wu" in English, for example), but I don't think that will really be an issue. --Yair rand (talk) 23:16, 2 February 2014 (UTC)
Why would we have a statement like that? If his given name was "Georg", that's what the statement should say. The way that English speakers refer to him can be indicated by the label of George Frideric Handel (Q7302). --Yair rand (talk) 21:45, 2 February 2014 (UTC)
The given name (P735) property shouldn't have been created at all, since no consensus about the datatype was reached. Alas, having the privileges to create a property is probably a stronger argument than having a support of a community. The arguments against the datatype were brought in the discussion about my deletion proposal (see also the discussion about P734 there), which was closed with the result "keep it until we have the MonolingualText/MultilingualText datatype and then let's reconsider." So I'm waiting for reconsidering. And hoping in the meantime, that this useless property doesn't cause much harm...--Shlomo (talk) 14:07, 2 February 2014 (UTC)
Don't think it will cause much harm in the meantime. However, it is useful to think of a way to transfer all the data under the current string property to the future multilingualText datatype while we are waiting for its deployment. --Wylve (talk) 16:35, 2 February 2014 (UTC)
I don't think there is any way to transfer the data to the multilingualText datatype. That's why I described this property as "useless". Technically, we may be able to extract the labels (what about aliases?) from the linked first name item in all available languages and add them as particular language variants to the multilingualText first name statement; but this is exactly what shouldn't be done. The item statement was (probably) added in respect to some language variant(s?) of the name, hence we should add the multilingualText statement only in this(these) language(s) - but we don't know which one it was. We can make a generalization and assume that the statements were made in English (but what if not...), or we can make some qualified guess like look for the preferred language of the statement creator (but what if bot...). In addition, we can cross-check with some kind of script, if the name of the Wikipedia page in the language in question contents the string we're going to add into the multilingualText statement. But sincerely, do we want to have Wikidata statements based on qualified guesses made by some kind of computer script?--Shlomo (talk) 18:05, 2 February 2014 (UTC)
All names should have items. There's an enormous amount of useful data we can add for these. If there are names missing items, that's a problem regardless of the datatype of these properties. --Yair rand (talk) 21:45, 2 February 2014 (UTC)
No, there are a lot of names which differ from a common name just by the form but they have the some root. Do we want to have all possible variations of all names ? And do not forget names from others cultures. Just to give an example: in France in one century there are 1'330'000 surnames see here. So the potential for the world is around 100 to 200 millions of names. we won't have all names in wikidata but by adding the persons which are notable and those used in references the potential for wikidata is in the range of the hundreds of thousands and tose are only names. Do the same with given names and and the combinaisons for persons. Snipre (talk) 22:30, 2 February 2014 (UTC)
France is not a typical country for this. According to the Guinness World Records list, France has more surnames than any other country in the world. So no, there are almost certainly not over 100 million surnames.
I don't understand the last sentence of your comment. --Yair rand (talk) 23:00, 2 February 2014 (UTC)
Do not only consider the current situation but include the past: wikidata doesn't focus on the 100 last years. Snipre (talk) 00:21, 3 February 2014 (UTC)


for second time... we need patroller, this ip user: has modified and merged many disambiguation pages now is very difficult to resotre all, I have not time to do this task --Rippitippi (talk) 23:38, 1 February 2014 (UTC)

I've checked over a couple of the merges and they look fine. What's wrong with them? Ajraddatz (Talk) 23:54, 1 February 2014 (UTC)
see rfd Q12030306 or Q12030721 etc.. he went on all day same one is right some one is wrong--Rippitippi (talk) 05:40, 2 February 2014 (UTC)
But... those seem to be fine merges? Why wouldn't Q12030306 be merged into Q1556886? Ajraddatz (Talk) 05:45, 2 February 2014 (UTC)
for this [1] "Only link together the same strings (sequences of characters) " [2]--Rippitippi (talk) 06:51, 2 February 2014 (UTC)
Hmm... besides the point that it is not a published guideline anywhere outside of the task force, I'd still say that the link from the former should be included in the latter. It's talking about the same things, as far as I can see. Ajraddatz (Talk) 18:09, 2 February 2014 (UTC)
Ajraddatz Please read second link [3] this is a community guideline but no one has take time for write it --Rippitippi (talk) 19:04, 2 February 2014 (UTC)
I read it, and suppose that is good... I guess at this point I just don't understand the result. It seems to go against common sense to have the same disambiguation pages on multiple wikis, but they can't link together because the names aren't identical. But this wouldn't be the place for changing that. Ajraddatz (Talk) 02:27, 3 February 2014 (UTC)
See also Wikidata talk:Disambiguation pages task force/guidelines for a recent discussion on this. Lymantria (talk) 06:50, 3 February 2014 (UTC)

Redundancy of Property:P373 for categories

I think Property:P373 for categories is redundant for direct links. Will be good idea if bots will convert property to link and delete property for category items. --EugeneZelenko (talk) 16:27, 30 January 2014 (UTC)

Please, keep attention that P373 us used by many templates in various wikis. Moving P373->commonslink will break articles using these templates.
BTW, how to use sitelinks in templates? e.g. when I want to use link for wikisource? JAn Dudík (talk) 19:50, 30 January 2014 (UTC)
Sure, property for categories could be declared deprecated and removed after awhile. BTW I asked about global property usage several months ago.
See w:ru:Шаблон:Писатель history and related Lua code (w:ru:Модуль:Wikidata/Wikisource) as example of links extraction.
EugeneZelenko (talk) 15:56, 31 January 2014 (UTC)
Nope. Commons links are main space and galleries (which are the same I think). Categories are to be linked by that property. John F. Lewis (talk) 20:22, 30 January 2014 (UTC)
It can sometimes (but not always) be regarded as redundant to the relation to topic's main category (P910), but it's not technically possible to use that route today. -- Lavallen (talk) 20:37, 30 January 2014 (UTC)
Please don't delete/replace Commons category (P373) yet. We need to have tracking and purging first before we can start doing that. Multichill (talk) 03:11, 31 January 2014 (UTC)
We can't replace it or delete it. John F. Lewis (talk) 15:42, 31 January 2014 (UTC)
Please note that I wrote about categories, not main space items. Why Commons categories could not be linked with Wikipedia/Wikisource/etc categories directly? I could understand apprentice of Property:P373 on categories items by historical reason (property was added before Commons support). But I don't see valid reason to keep that obsolete implementation forever because links are definitely better from maintenance point of view. --EugeneZelenko (talk) 15:56, 31 January 2014 (UTC)
First we then need a big remake of the category-tree at Commons. But I do not think that ever will be finished, Achilles and the tortoise you know... -- Lavallen (talk) 16:03, 31 January 2014 (UTC)
I don't think that this problem is related to the remake of the category-tree at Commons. In a category-item, e.g. Category:Berlin (Q4579913), the commons category is stored twice. Once as the value of P373 and a second time as sitelink. So it makes sense to discuss the removal of P373 statements in category-items. Why is the template commonscat needed on category pages if one could also do the linking (from category to category) in the left navigation bar? --Pasleim (talk) 16:27, 31 January 2014 (UTC)
The category-tree for municipalities in Sweden is for example only half done. The category for the municipality is often shared with the category for the namesake-city in the municipality. And you can only create a sitelink to one of the categories here, the municipality-category or the city-category. But with P373 both the city- and municipality-category can link to the same commons-cat. -- Lavallen (talk) 16:36, 31 January 2014 (UTC)
Sure, it's good idea to resolve such conflicts. But are they rule or exception? Could we have statistics of duplicated Property:P373 values for categories items? Other useful check: categories items with Property:P373 but without Commons link, if such link is not used in other item(s). Shouldn’t we have constraints on such matters? --EugeneZelenko (talk) 03:48, 1 February 2014 (UTC)
@Byrial: let's make some queries ;-) --Ricordisamoa 14:46, 2 February 2014 (UTC)
Ok, I did the query. There are 8761 P373-values which are used by two or more category items (see full list). However, there are also many merge candidates. In total, I counted 2048 pairs which can be merged sharing 1663 different P373-values (merge list). And of course, there are many questionable P373 claims. --Pasleim (talk) 08:15, 3 February 2014 (UTC)
Wikidata:Database reports/Constraint violations/P373‎ - there are duplicated category links. JAn Dudík (talk) 07:48, 3 February 2014 (UTC)

"In other languages"

This morning I have a new feature added to the item pages, which I had never had before. I don't even think it's new, but for some reason it has only now become accessible. It's good too, seeing as I use "labelLister" a lot. However, how can I change the languages offered? Aside from English (default, at the top), I have the following three languages offered to me in which to add labels and descriptions: Deutsch (de), Plattdüütsch (nds) and Türkçe (tr). I tried adding/changing one of these languages to Russian, but it won't work. Does anyone have any tips? Jared Preston (talk) 05:03, 31 January 2014 (UTC)

Oh, as I now see from Lydia in the thread above, it is new! Cool. But do I have to add/create a babel box on my userpage in order to change the languages offered? Jared Preston (talk) 05:06, 31 January 2014 (UTC)
It's a great idea, new - and still a bit buggy. With babel it should work, but this night it was like gambling. I have 5 babel languages "installed" but the pages keep changing to Italian and languages with non roman letters I've never used. (For example an article with the last edit in Farsi was keeping showing the page in Farsi whatever I tried.) --Kolja21 (talk) 05:15, 31 January 2014 (UTC)
I can't say I like it; a longer time for the page to load and even more of the page to scroll through to get to the parts of the page that matter (why not put such new gizmo's at the bottom?). The UI was bad enough as was. - Brya (talk) 06:24, 31 January 2014 (UTC)
The page load time can't be noticeable longer ;-) The box has existed for a long time. It just wasn't obvious how to get it so nearly no-one used it. --Lydia Pintscher (WMDE) (talk) 06:55, 31 January 2014 (UTC)
We get suggestions from ULS for languages you likely speak. It might well be that those are something a bit strange ;-) --Lydia Pintscher (WMDE) (talk) 06:55, 31 January 2014 (UTC)
Yes. Add babel boxes to your user page and it will pick those languages instead. --Lydia Pintscher (WMDE) (talk) 06:55, 31 January 2014 (UTC)
Ooooh, it works. Thanks Lydia! Jared Preston (talk) 07:40, 31 January 2014 (UTC)
Not sure whether it is related - I just noticed that on at least two items I got the header "Wikipedia pages linked to this item" and all headers below in Italian (all headers above that one were in English). I have English installed as my preference language, but I list Italian in the babel template on my page. Apparently, smth happened with the fallback which should not have happened - these messages should always be in the preference language.--Ymblanter (talk) 09:08, 31 January 2014 (UTC)
If the loading times really are longer is hard to tell, but they are not going down. Adding a babelbox proves not to help. -Brya (talk) 12:08, 31 January 2014 (UTC)
To illstrate my own examle: Q412957 I see mostly in Russian--Ymblanter (talk) 12:17, 2 February 2014 (UTC)
That is an ugly caching issue :/ We're working on it. It is unrelated to the in other languages box. You can track progress at bugzilla:60715. --Lydia Pintscher (WMDE) (talk) 11:40, 3 February 2014 (UTC)
  • I don't know if it is related issue but: some pages, when I load them after viewing their history of some diff, displays in not my language. And moreover I cannot switch them to Russian in any way after that. One of them is Q957016. Infovarius (talk) 18:31, 3 February 2014 (UTC)

Status update on entity suggester

Hey folks :)

As I mentioned here previously a team of students is working with us to get the property suggester done. They've made huge progress over the last weeks. They now have a demo where you get nice suggestions for new properties to add. Test it out yourself by adding a new statement on I'm sure they'd love to hear your feedback. --Lydia Pintscher (WMDE) (talk) 13:27, 3 February 2014 (UTC)

Doesn't seem to be ready to be tested yet. Any click on "[edit]" just results in a spinner icon for a while and nothing else happening (Firefox 26.0). A link to add new statements is missing in the first place. --YMS (talk) 13:34, 3 February 2014 (UTC)
Then not all JS was loaded for you. Can you reload the page or try it in a different browser please? (It works here.) --Lydia Pintscher (WMDE) (talk) 13:36, 3 February 2014 (UTC)
Only difference in Internet Explorer (don't have more other browsers at work) is that any click on "edit" redirects me to the Main Page. Both browsers show a syntax error in the console when I load an item, by the way. --YMS (talk) 14:04, 3 February 2014 (UTC)
Why do you click [edit]? Click [add]. Working fine here. --Stryn (talk) 15:24, 3 February 2014 (UTC)
[edit] and [add] both have exactly the same (i.e. no) function here. But well, if it's only me it's okay for now. I just wanted to avoid that myriads of people click the link, see it not working and are disappointed or confused only because the testing environment is not yet set up completely. I'm sure the problem that affects me will be resolved some time. --YMS (talk) 15:34, 3 February 2014 (UTC) PS: Oh, and by "[add]" here I mean the "[add]" by which I should be able to add another claim to an existing statement, the "[add]" to add a complete new statement is missing, as stated initially. --YMS (talk) 15:38, 3 February 2014 (UTC)
Ah, sorry, I didn't see that you wrote "a link to add new statements is missing in the first place". Then, I don't know what's wrong, sounds like some JS problems. I can see the button, and suggests, and it's very handy (because can see some properties without need to think about what should I add). --Stryn (talk) 17:15, 3 February 2014 (UTC)


Anybody has any idea what was going on with this item and how it could be repaired? Simple undo did not work for me, I got an unintelligible error message.--Ymblanter (talk) 20:03, 3 February 2014 (UTC)

It looks like the MediaWiki message for the error no longer accepts HTML in the input. Not sure what message it is.
I deleted the offending item and restored the previous revision. Did someone ask the user what he was doing? --Izno (talk) 20:17, 3 February 2014 (UTC)
Thanks. I let them a note now, but I am not sure they speak English.--Ymblanter (talk) 17:23, 4 February 2014 (UTC)

Notability change

From now on, subpages of templates and modules are included with these two exceptions:

  1. /doc, /sandbox, /testcases or /TemplateData subpages are excluded.
  2. items with only one sitelink about a subpage of a template are not allowed.

--GZWDer (talk) 14:10, 4 February 2014 (UTC)

How about introducing a filter to prevent the creation of /doc, /sandbox , /testcases and /TemplateData items? I'm afraid that even though we delete them now, someone in the future will create them again... — TintoMeches, 14:32, 4 February 2014 (UTC)
I created a list with items which have sitelinks to excluded template subpages: User:Pasleim/Unsupported sitelinks. If you wish, I can do updates regularly. --Pasleim (talk) 18:52, 4 February 2014 (UTC)
@Pasleim: Swedish (sv) items who end with "/dok" have the same function as those who end with "/doc", you can add them to, if you find any. -- Lavallen (talk) 19:47, 4 February 2014 (UTC)
@TintoMeches: New filter introduced. Matěj Suchánek (talk) 20:01, 4 February 2014 (UTC)
Thanks everyone! — TintoMeches, 20:22, 4 February 2014 (UTC)

ISSN bot

Could I have some feedback on Wikidata:Requests for permissions/Bot/JVbot, as I operate and monitor this task over the weekend. John Vandenberg (talk) 07:05, 31 January 2014 (UTC)

The majority of the infoboxes have been processed - there are a few languages left to reconcile. Several duplicates have been identified and fixed on Wikipedias in the process (e.g. bn:উইকিপিডিয়া:প্রশাসকদের_আলোচনাসভা#Scientific_American and fa:ویکی‌پدیا:قهوه‌خانه/گوناگون#Journal_of_Homosexuality). Now I would like to create missing items, so feedback on Wikidata:Requests for permissions/Bot/JVbot 2 would be appreciated. John Vandenberg (talk) 17:01, 5 February 2014 (UTC)


Whatever happened to the text at Special:NewItem? There's now a message saying "By clicking "save", you agree to the terms of use, and you irrevocably agree to release your contribution under the Creative Commons CC0 License" and a redlink going from "terms of use" to Wikidata:Copyrights, that's never happened before. TeleComNasSprVen (talk) 07:32, 5 February 2014 (UTC)

Oh, it seems to be linked from MediaWiki:Wikibase-shortcopyrightwarning which was deleted by Hoo man the other day; @Hoo man: can you comment on this deletion? TeleComNasSprVen (talk) 07:34, 5 February 2014 (UTC)
A local version only reaches the users who have an English interface. It would be better if we could use a smarter solution. -- Lavallen (talk) 07:51, 5 February 2014 (UTC)

More quantities

attendance (P1110), votes received (P1111), P1112 (P1112), number of episodes (P1113), quantity (P1114) were created. Especially 1113 and 1114 might be a duplicate relation. --Tobias1984 (talk) 19:07, 1 February 2014 (UTC)

Even more needing translations and addition to various WikiProjects: ATVK ID (P1115), ELSTAT geographical code (P1116), pKa (P1117), P1118 (P1118), P1119 (P1119), number of deaths (P1120), oxidation state (P1121), spin quantum number (P1122), parity quantum number (P1123), P1124 (P1124), Gini coefficient (P1125), isospin quantum number (P1126), isospin z-component (P1127), employees (P1128), national team caps (P1129) --Tobias1984 (talk) 14:58, 2 February 2014 (UTC)
The usefulness of national team caps (P1129) is highly debatable. A sportsperson can play for different national teams, either because he immigrated to another country or because he plays several sports. It would be more appropriate to use a qualifier "number of matches played" with the property member of sports team (P54), which would enable us to process all potential cases. --Casper Tinan (talk) 22:03, 2 February 2014 (UTC)
national team caps (P1129) can only be relevant to a sporting team as a qualifier to a team — be it national/region/club — so I support @Casper Tinan:'s comments. "number of matches played"  — billinghurst sDrewth 09:14, 3 February 2014 (UTC)

Can someone explain to me the use and usefulness of P1118 (P1118) and P1119 (P1119)? If rankings change on a monthly basis, then we are going to have 12 rankings per player, for between 1 and 15 years of play (equates to 12 to 225 data points!). For what value? I could understand if the ranking was determined at a standard annual reference point of time (eg. end of year), or if a highest ranking was identified at a point in time, but not a continuous ranking. At face value it would seem that we have lost the plot.  — billinghurst sDrewth 09:30, 3 February 2014 (UTC)

I think this is just an UI problem. After 10 statements are added to a property it should switch to a more compressed table view. I don't think that 225 data points is a lot. We are going to have a lot of properties with more data points. A lot of cities are going to get a huge list of past mayors for example. --Tobias1984 (talk) 10:46, 3 February 2014 (UTC)
It is a pointless problem. For one, who will care? Apart from maybe the top twenty players it simply isn't going to happen, let alone on a regular basis unless you are going to organise a data feed, and make that property when you have the data feed, not at some "there is an idea" moment. Property creators are meant to be the gatekeepers, adding rigor to the creation process, to stop the cruft. Please also don't ignore the comment in the prior paragraphs about 'number of matches played' and wider functionality.  — billinghurst sDrewth 11:38, 5 February 2014 (UTC)
We have Wikidata:Tennis task force and it is up to them to decide what properties they need. The community has voted in favour of the property and I will follow that vote unless I think something is seriously wrong with the property. I have probably already posted this here 10 times: More people have to critically participate in the property proposals. They are at the core of Wikidata and the amount of attention they get is sub-optimal. --Tobias1984 (talk) 12:09, 5 February 2014 (UTC)
On Wikipedia, we have parameters "current singles/doubles ranking" and "highest singles/doubles ranking". I think that it is not meaningful to add every rankings (which are updated almost every Monday, so 52 rankings/year). Jarkko Nieminen (Q10270) has 769 rankings ([4]). That's why I thought that we should add just those properties (highest / current rankings). Also, if we have some property for showing chart positions of an album, maybe better to just add the peak position, not positions of every week, but this is just my opinion. But in the end, ranking properties are much needed, because we have so many tennis player articles on many Wikipedia's, and many articles are not up-to-date with rankings. So if ranking are coming to articles from Wikidata, it's a big improvement. --Stryn (talk) 18:12, 5 February 2014 (UTC)
In my opinion Wikipedia is an unbelievable huge collection of information. We have to accept that Wikidata will be a hundred or thousandfold of Wikipedia in order to be useful to Wikipedia. 10 Mega-Items will result in 1 or 10 Giga-Statments. So we can't really complain about 52 x average-career-lenght. --Tobias1984 (talk) 19:16, 5 February 2014 (UTC)

Detecting disambiguation pages linked with content items

I noticed that some disambiguation pages were linked with content items (example: Q649s:ru:Москва). I think will be good idea it bots will check pages specified links for usage of Q6148868. --EugeneZelenko (talk) 04:48, 5 February 2014 (UTC)

  Support There is also an outdated page User:Sk!dbot/disambiguation page conflict. Matěj Suchánek (talk) 19:53, 5 February 2014 (UTC)

Linking to Commons

What's the difference between the statement "Commons category" and the property "Wikimedia Commons page linked to this item"? Komischn (talk) 20:41, 25 January 2014 (UTC)

The former is a statement (Commons category (P373)), while the latter is a sitelink: see Wikidata:Commons. --Ricordisamoa 20:59, 25 January 2014 (UTC)
Isn't Commons category (P373) redundant to the combination of topic's main category (P910) and the category-item's sitelink? We don't bother including all of the other sitelinks of a category-item on the topic-item. --Arctic.gnome (talk) 21:04, 25 January 2014 (UTC)
Not really. Commons category (P373) links to the Commons category while topic's main category (P910) does not. John F. Lewis (talk) 21:12, 25 January 2014 (UTC)
So which one am I supposed to use when linking from a person's article to their Commons category? --Komischn (talk) 21:31, 25 January 2014 (UTC)
Commons category (P373) John F. Lewis (talk) 21:34, 25 January 2014 (UTC)
Thank you. --Komischn (talk) 12:37, 27 January 2014 (UTC)
What if there isn't a separate Commons page for a specific item (only a category)? Can I link to its Commons category using the sitelink property then? --Komischn (talk) 13:31, 31 January 2014 (UTC)
Nope. John F. Lewis (talk) 15:40, 31 January 2014 (UTC)
The problem is, when leaving the sitelink property empty, no interwiki links will be displayed on the Commons category page. Is that likely to change anytime soon? I think interwiki links are more important than a strict distinction between Wikipedia articles and Commons categories if there is no counterpart. --Komischn (talk) 21:03, 31 January 2014 (UTC)
Actually the discussion at RfC Commons links came to the opposite conclusion; the distinction between namespaces are more important than interwiki links. However, you are most welcome to create a template on Commons that fetch the lable and description the categorys main topic. /ℇsquilo 07:54, 1 February 2014 (UTC)
We do have a problem here though, which is not entirely related: we have not imported all of the hundreds of thousands of categories for which a category on other wikis does not exist but for which a main topic does. (And these should be imported, but not to the "mainspace items" per the RFC—to new items which are then linked by the topic's main category and category's main topic claims.) Who wants to raise their hand for that? --Izno (talk) 20:58, 6 February 2014 (UTC)

first written record

Do we already have a property for "first written record"? E.g. as in "Munich was first mentioned in 1158" (in Augsburger Schied)? --Slomox (talk) 10:04, 4 February 2014 (UTC)

As far as I am aware of (though I don't monitor property proposals closely), we don't have such a property yet and it has never been proposed (while something smilar was suggested in a project discussion: Wikidata talk:WikiProject Mineralogy/Properties/Archive/2013/09#Properties). Go ahead, I'd say. --YMS (talk) 16:14, 4 February 2014 (UTC)
Great idea ! Plus, it could be useful for the wiktionaries in a (distant) future. A galon, VIGNERON (talk) 19:24, 6 February 2014 (UTC)
@YMS, VIGNERON: This discussion was opened at Wikidata:Property proposal/Place#first written record. --Izno (talk) 21:14, 6 February 2014 (UTC)

Quantities! For real!

Hey folks :)

We have just deployed the initial version of quantities here. This means you are now able to enter things like the number of inhabitants of a country. In future versions we will add support for units to this. It might take a bit for all properties to be created that were waiting for the quantities datatype. I hope you'll do awesome things with it!

Cheers --Lydia Pintscher (WMDE) (talk) 23:40, 30 January 2014 (UTC)

IRC stalking causes Human Development Index (P1081). Thanks for the development too. John F. Lewis (talk) 23:42, 30 January 2014 (UTC)

And of course in all the excitement about quantities I forgot the other important stuff:

  • We added the "in other languages" box for everyone also when they don't have a babel box defined on their user page. The universal language selector guesses which languages the user likely speaks and we use those.
  • We made a few more performance improvements.
  • Revisions of items that have been RevDeled or suppressed (by oversighters) can be viewed again (bugzilla:58027)
  • We fixed the "claim index out of bounds" bug.

--Lydia Pintscher (WMDE) (talk) 00:11, 31 January 2014 (UTC)

  • That one looks right to me. Could you describe the mess? --Tobias1984 (talk) 09:27, 31 January 2014 (UTC)
  • Ok, I got to replicate the mess. orbital eccentricity (P1096) currently looks like this, but only in the English page: "Data type & l t ;datatypes-type-quantity & g t ;" --Tobias1984 (talk) 09:49, 31 January 2014 (UTC)
  • In Italian page the datatype is correct (Quantità) and P1096 works well (see (Q2). --Paperoastro (talk) 10:15, 31 January 2014 (UTC)
  • Yes, it is that one indeed.--Ymblanter (talk) 10:12, 31 January 2014 (UTC)
Is it possible to remove the uncertainty for values (e.g. hydrogen (Q556) having 1 ±1 for atomic number (P1086) is wrong)? --Wylve (talk) 09:43, 31 January 2014 (UTC)
  • I also noticed that already on test-wikidata. That is also why I thought the datatype is not ready yet. The error of the atomic number is by now 0, because it is a matter of definition now. Only the measurement of the atomic number can have a deviation from the expected-value. Currently I think only bots can set a different standard deviation. --Tobias1984 (talk) 09:47, 31 January 2014 (UTC)
  • It is possible, but you have to first save it with the wrong deviation and then edit it again. --Rschen7754 09:49, 31 January 2014 (UTC)
    I tried with Q4252909 (population), did not work for me.--Ymblanter (talk) 12:37, 31 January 2014 (UTC)
Have to changed the ±1 to a ±0, and you're done. Ahoerstemeier (talk) 13:36, 31 January 2014 (UTC)
Indeed, it worked, thanks.--Ymblanter (talk) 13:47, 31 January 2014 (UTC)
  • Right now this new type seems to be broken and unusable. Danrok (talk) 12:24, 31 January 2014 (UTC)
Works for me in Täby (Q54337) -- Lavallen (talk) 12:31, 31 January 2014 (UTC)
Works also for me in Earth (Q2) and Messier 82 (Q14026) --Paperoastro (talk) 13:05, 31 January 2014 (UTC).
Which browser are you using? These items are broken looking in Chrome Version 32.0.1700.102 m on Windows 7. But, look fine for me using FireFox. Danrok (talk) 13:35, 31 January 2014 (UTC)
I'm using Firefox on Ubuntu 12.04. --Paperoastro (talk) 15:27, 31 January 2014 (UTC)
Now it works for me in Chrome. No idea what has changed. Danrok (talk) 19:41, 31 January 2014 (UTC)
  • Making a second edit to get rid of the ±1 worked for me. --Jakob (talk) 13:59, 31 January 2014 (UTC)
Apparently you don't need a second edit. Typing value+/-0 works for me on the first edit. --Wylve (talk) 15:36, 31 January 2014 (UTC)

More properties: number of masts (P1099), number of cylinders (P1100), floors above ground (P1101), flattening (P1102), number of platform tracks (P1103), number of pages (P1104),Sandbox-Quantity (P1106), proportion (P1107), electronegativity (P1108), refractive index (P1109). --Tobias1984 (talk) 16:55, 31 January 2014 (UTC)

I think that I don't understand how does this work. I created Prize money property, and tried to add "6,785,454" as a value, but it was not possible to save. Then I tried "6 785 454", still no. Isn't it fully implemented it, or am I doing something wrong? --Stryn (talk) 17:09, 31 January 2014 (UTC)

  • There are a whole lot of oddities with this datatype. There are many situations where non-integer values wouldn't mean anything, yet +/-1 is still there. Also, why is this edit displayed like that? --Yair rand (talk) 22:22, 2 February 2014 (UTC)


Does what I have done in Stockholm urban area (Q94385) any sense? If you look into page 15 in the source-pdf, you can see what I have done. Stockholm urban area was already 1960 in parts of 9 municipalities. Unfortunatly none of them have any article outside svwp. -- Lavallen (talk) 15:53, 31 January 2014 (UTC)

I think it makes sense. Thanks for putting so much work into this very difficult subject. I looked at the report to find the standard deviation. Shouldn't it be like 2 or 3 % or maybe Poisson counting error: squareroot(total)? --Tobias1984 (talk) 20:46, 31 January 2014 (UTC)
I know nothing about the precision of these numbers. And I do not know how interesting I think that discussion is. It is of more interest for me if the method, with the use of applies to part (P518) and point in time (P585) is correct. -- Lavallen (talk) 08:37, 1 February 2014 (UTC)
@Lavallen: We should make Stockholm urban area (Q94385) a featured item, then other people see how to add statistical data to complex regions. I certainly like the approach. --Tobias1984 (talk) 08:43, 1 February 2014 (UTC)
Not sure about the use of applies to part (P518) there. It's one property I would use when that part of the entity is "very un-notable" (e.g. the windows of an A380 aircraft), but not when that "part" is notable enough for having its own item. I think those data should be placed in the items of those sub-divisions themselves. --Wylve (talk) 08:48, 1 February 2014 (UTC)
@Wylve: Observe that the statistics here does not tell that "Stocksund market town" has a population of 5027, but that Stockholm urban area has a population of 5027 in Stocksund market town. How high the population is outside Stockholm urban area in Stocksund market town is not known by this census. It's possible that Stockholm cover all of Stocksund, but it does not tell anyhting about it. It's possible that Stockholm urban area does not even cover all of Stockholm city. Not even today, Stockholm urban area cover all of Stockholm municipality. There is even room for rural areas in Stockholm municipality today, which isn't counted inside any urban area. You may compare urban areas with lakes. They can be divided by borders, but they normally never cover all of any administrative unit. -- Lavallen (talk) 09:39, 1 February 2014 (UTC)
I see, thanks for the clarification. --Wylve (talk) 09:58, 1 February 2014 (UTC)
Hi, good work Lavallen. I just added a statement to say that this urban unit is a instance of (P31) <Stockholm urban area (Q94385)>. But, checking the french description of this item, there could be several definitions of urban units … If so, which one is used here ? TomT0m (talk) 15:39, 1 February 2014 (UTC)
I have used instance of (P31) urban area in Sweden (Q12813115) to separate Swedish urban areas from other definitions. The Swedish definition from 1960 is in big parts the same as is used in Denmark, Norway and Finland. (population>200 <200 meters between populated buildings, how many holiday and weekend homes are allowed in an urban area and how water is treated can be different during different census) There should only be details separating the Swedish version from the other Nordic nations, but the definition can be very different from other nations in the world. The pre-1960 definition in Sweden is not well-defined from one census to another, and not always the same in all counties. I will therefor use other items for those entities, if I ever will come so far. Those documents are not digitized so everything have to be done by hand... -- Lavallen (talk) 17:43, 1 February 2014 (UTC)
I created a class item (urban unit definition (Q15700808)) of which these definitions are an instance of, this should be useful. Just a remak from your census source : it's too vague, it does not tell which one it is. TomT0m (talk) 19:23, 1 February 2014 (UTC)
Looks good! @TomT0m: Which one do you refer to? The Swedish urban area-census-sources I have used are linked in my userpage. It's every five years from 1960-2010, (except 1985 when the municipalities revolted, and refused to do the census because of the costs). -- Lavallen (talk) 12:41, 2 February 2014 (UTC)

Precision by default

Why is the inteface adding a precision by default (apparently based on the number of decimals) That does not sound good to me. For scientific data, we should probably let users define the precision themselves. For things like population and such, most users do not have any idea about how reliable the data are, and perhaps more to the point, the source itself does not give any idea about the precision of its data. I think the default precision should be +- zero so that it does not give the impression that we have really provided info about the precision. --Zolo (talk) 14:08, 1 February 2014 (UTC)

The datatype was somehow deployed before being ready. But at least this way we can talk realistically about improving it. The default precision is a problem, but people just have to be careful what values they are adding. If the source doesn't estimate the precision we should probably just leave it blank. When we get to the point where people query the data, we can return it with an empirical value for the precision. --Tobias1984 (talk) 15:48, 1 February 2014 (UTC)
My proposal, (and we have discussed it regarding orbital element for solar system objects) is to use a qualifier when the precision is defined as a standard deviation. The present system gives a range and it does not fit for standard deviation in my opinion. -- Lavallen (talk) 17:48, 1 February 2014 (UTC)
Precision based on number of decimals have been used for coordinate location (P625) since geographical coordinates was introduced to Wikidata. No problem with that, so what's the problem with using the same method for numbers? /ℇsquilo 19:33, 1 February 2014 (UTC)
There are some numerical properties which do not even need the concept of precision see e.g. atomic number. This seems to me then that the default should have no precision... Then of course as above there needs to be a method to use standard deviations as a precision, as well as the current range. And then there will be cases where we need to get precision with a percentage confidence (you could say the percentage confidence in terms of the standard deviation but that might not be faithful to the underlying data). Lastly, I can imagine a case where you need the range and percent confidence…. --Izno (talk) 03:51, 2 February 2014 (UTC)

I strongly suggest that the interface should stop adding precision by default. ±1 for integers is arbitrary. For example in population (P1082) , the number according the census will be either exact or a much more wide precision which will be mentioned in the sources. It is unproductive if we need a second edit to get rid of a precision that is not helpful to most cases. -geraki talk 17:10, 7 February 2014 (UTC)

Can't turn off some gadgets

I'm wondering why I can't turn off 3 gadgets on my preferences: Search, AuthorityControl and CommonsMedia. Is it just me or everyone? Bug or what? --Stryn (talk) 16:15, 31 January 2014 (UTC)

I'm having the same problem. It does not seem to give any indication why the gadgets cannot be disabled. The Anonymouse [talk] 18:06, 31 January 2014 (UTC)
Also "Redirect image links to Commons for files that are hosted there" and "Some enhancements on WD:RfD (enabled by default just for admins)" belongs to those gadgets which I can't disable. Even restoring all to default settings didn't help. All gadgets which are "enabled for everyone by default" are gadgets which I can't disable. Maybe it's a bug? --Stryn (talk) 13:48, 2 February 2014 (UTC)
This does indeed sound like a bug. I don't think however it is specific to Wikidata. We're not doing anything special there afaik. --Lydia Pintscher (WMDE) (talk) 11:56, 7 February 2014 (UTC)
I was going to make a bug report, but I wanted to test yet, and it was working again like it should, so no need to file a bug. --Stryn (talk) 14:51, 7 February 2014 (UTC)

File in Commons linkage

Is it OK to put files in the Commons box at the bottom as it was done in Q61209 and Q2140812? --тнояsтеn 07:26, 4 February 2014 (UTC)

No, singles files like these should be used with image (P18). --Kolja21 (talk) 07:36, 4 February 2014 (UTC)
  Done I've corrected the edits. --Kolja21 (talk) 07:40, 4 February 2014 (UTC)
Thanks. Any idea how to prevent users from using files in the wrong place? --тнояsтеn 07:56, 4 February 2014 (UTC)
You may be interested to know that AbuseFilter 37 now tracks this. Delsion23 (talk) 11:37, 7 February 2014 (UTC)
Thanks! --тнояsтеn 16:42, 7 February 2014 (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. тнояsтеn 16:42, 7 February 2014 (UTC)

red link for IPs

If an IP wants to add label it shows a message with "By clicking "save", you agree to the terms of use..." (I think it is This message, see also that one), "terms of use" is linked with "Wikidata:Copyright" which was deleted, so I propose to link it with wmf:Terms of Use, but I can't edit. --Bigbossfarin (talk) 20:54, 4 February 2014 (UTC)

Oh sorry, didn't notice this thread when I opened the one just down below. TeleComNasSprVen (talk) 18:26, 7 February 2014 (UTC)

javascript issues

Hi! I have had a lot of trouble with Wikidata in recent months not loading properly/crashing browsers, etc., due to scripts hanging or not loading. I typically use Firefox, but it's up to date and I've had the issue with various configurations and on Windows & Linux systems. Others? Just me? If it's just me I can get more specific about the errors. I have various gadgets enabled, but tested with and without userscripts and I don't think there's a particular script that's causing hangups. -- Phoebe (talk) 20:45, 6 February 2014 (UTC)

I think the bug is already being tracked. I'm using Ubuntu 13 and Firefox 26 gets a lot of errors. Chromium works better, but it all depends how many statements an item has. --Tobias1984 (talk) 21:03, 6 February 2014 (UTC)
@Phoebe: This is actually a high priority issue that Lydia needs to get resolved and which she already knows about. (From what I can tell, it's mostly a) inefficient Javascript and b) Javascript which should really be in PHP instead.) --Izno (talk) 21:09, 6 February 2014 (UTC)
Yes, Firefox 26 & high-statement items seems to crash it the most. Izno, good to know, thanks! I just wanted to make sure we were already aware :) -- Phoebe (talk) 01:40, 7 February 2014 (UTC)
Yeah. It's a known issue the developers have been working on over the last month and some. bugzilla:54098 for tracking it. --Lydia Pintscher (WMDE) (talk) 11:59, 7 February 2014 (UTC)

Include property in infobox if it exists

I want to show a commons image in a wikipedia infobox automatically but only if it exists as image property (P18) on wikidata. I know this is more a question about mastering infoboxes but maybe someone here could know. Basically what is needed to be able to check whether a property exists at all... if it does not, does not show the infobox field at all.--Kozuch (talk) 14:16, 7 February 2014 (UTC)

There're two methods:
  1. Use {{#property:PXXX}}, if P18 statement doesn't exists, an empty string will be returned. This is easy to detect using {{#if:}}. However, if there're more than one P18 statement, {{#property:PXXX}} will return "A.jpg, B.jpg", and there will be an error including this.
  2. Use Lua, There'll be easy to solve this problem. see mw:Extension:Wikibase Client/Lua.
--GZWDer (talk) 14:54, 7 February 2014 (UTC)

A double ontology for astronomical objects

After a first discussion here, I propose two different ontologies for astronomical objects. The proposals and the discussion are here. Please anyone interested, especially people that commented the first discussion, to participate. Thanks. --Paperoastro (talk) 23:37, 7 February 2014 (UTC)

Advise on how to do the following search

I am trying to get a list of all the Wikipedia articles that have the following attributes:

1) They have simultaneously corresponding articles in Wikipedia in ALL the following languages : ENGLISH, DUTCH, GERMAN, SWEDISH, FRENCH and ITALIAN (they may have or not in other languages but I do not care). (This would mean that there is interwiki information on WIKIDATA in ALL these languages for each of the selected articles.


2) There is no corresponding article in the SPANISH Wikipedia.

The final objective to spot Wikipedia Articles that are absent from SPANISH Wikipedia, but that do exist in the six Wikipedia identified above.

I would very much appreciate some guidance on how can this search be carried out. Or eventually if there is a caritative and helping hand, to help me get such a list.


Uruk- Uruk (talk) 03:44, 8 February 2014 (UTC) (Uruk Spanish Wikipedia)

Status of pending property proposals

I apologize if it is not the right page to ask this kind of questions but i did not find any explanation about the status of the property proposals appearing in the pending pages. Have they already been approved and are just waiting for an administrator to create them ? Are they still to be debated upon ? Can we still ask for modifications or improvements ? Thanks in advance for the information. Casper Tinan (talk) 22:37, 5 February 2014 (UTC)

Most of those are awaiting the technical support for the data types. --Yair rand (talk) 22:53, 5 February 2014 (UTC)
Thanks for the information. I have written my opposition to a few of the pending proposals. Hope a debate about them can still take place. Casper Tinan (talk) 14:28, 8 February 2014 (UTC)


I have been trying to get Fishing Creek (Q5455008) to Showcase item status. However, the label/description is only in three languages (English, French, and Latin), and I do not know any other languages. Is there someone who could add some additional translations of the label/description of Q5455008? Thanks, --Jakob (talk) 01:38, 8 February 2014 (UTC)

Cedrus Q128550

Hi. I have a question about these number of edits. Is there any chance to monitor/control that a link to my native wiki is removed? and of course to control that all links are cleared? --Vera.tetrix (talk) 10:05, 8 February 2014 (UTC)

i don't know why Diako1971 removed all links and only reconnected one of them to another item. i have restored Cedrus (Q128550). @Diako1971: if there are wrong links, please move them to correct items (see Wikidata:Tools/Gadgets#Move or Help:Merge), but not only delete them.
@Vera.tetrix: you should be able to notice every change on Wikidata on your local Wikipedia (recent changes, watchlist). To see these changes you might need to click "show Wikidata" somewhere (different options, depends on which special page you use). For monitoring here we have User:KrBot/Lost links, but it is only for new editors, not for more active users like Diako1971. Holger1959 (talk) 12:43, 8 February 2014 (UTC)
Had both options enabled, but just discovered, that "show wikidata" option is not working together with grouping (also was enabled for me). Seems now it shows absolutely all changes for connected items, but maybe one day it will be possible to sort/filter only changes connected with one(or some) particular wiki or language. Thanks for your help! --Vera.tetrix (talk) 16:45, 8 February 2014 (UTC)

Flavor Q4173974 and Q3055388

Hello. There is a problem with interwikis Q3055388 and Q4173974. I think the source is the English article en:flavor. The entry Q3055388 (arôme, aroma) has no link to flavor, an article about "aroma", because flavor is linked to Q4173974 (german Geschmack). Or maybe the source is the german wikipédia where there are two entries for "Geschmack" (taste) de:Geschmack (Sinneseindruck) and de:Gustatorische Wahrnehmung which has a link to en:taste. I only speak German, French and English and don't know how to correct entries to have all articles about "aroma" in food industrial sense linked together. Traumrune (talk) 11:48, 8 February 2014 (UTC)


Can someone with knowledge of how Wikidata works add to the list of jargon used at Wikidata:Glossary about what the referred to term "semantics" mean? I see it used a lot around here, but I'm not sure if it corresponds to the "syntax-semantics" relationship in normal languages. TeleComNasSprVen (talk) 18:47, 7 February 2014 (UTC)

I suppose it just means "meaning". Infovarius (talk) 21:14, 8 February 2014 (UTC)
Yep. By design Wikidata has nothing like a language semantic like in programming languages. The closest thing we have to a formal semantic is Help:Basic membership properties, which are supposed to be aligned to their (formally defined) analog in the OWL and RDF/RDFS languages from W3C for the semantic web. Hence we are mainly discussing on which property we should use when we want to say something, which property we have to create and how we should use them in english. There is also some constraints which defined some (mainly only syntactic) way the property and value should be used. TomT0m (talk) 21:53, 8 February 2014 (UTC)

New RfC about given names and surnames

Sorry for mis-using the chat for signalling a RfC, but I think this is a relevant issue that Wikidata can help to finally solve: Wikidata:Requests for comment/How to deal with given names and surnames. Please, have your say. :) --Sannita - not just another sysop 16:21, 9 February 2014 (UTC)

Q728279 ; Q3317796

to be merged ; thanks ; JLM (talk) 16:34, 9 February 2014 (UTC)   Done. TomT0m (talk) 16:58, 9 February 2014 (UTC)

Place in china called tyrannosaurus rex

Is there really a place in China that is called T rex? Shishang Village (Q14416325)? --Tobias1984 (talk) 15:17, 4 February 2014 (UTC)

According to Google translate, the Chinese label (石上村) says Stone Village. — TintoMeches, 15:31, 4 February 2014 (UTC)
Only edit of, probably a vandalism. Cdlt, VIGNERON (talk) 16:05, 4 February 2014 (UTC)
Dealt with. --Wylve (talk) 16:09, 4 February 2014 (UTC)
Thank you all. Although now I am sad that there is not place called "T rex". --Tobias1984 (talk) 16:24, 4 February 2014 (UTC)
You may want to see lists like place names considered unusual (Q3080368) or Wikipedia:Unusual place names (Q15709593) to restore your good mood (though there's actually no T-Rex on any of them...). --YMS (talk) 16:43, 4 February 2014 (UTC)
Those are indeed "unusual" :) --Tobias1984 (talk) 16:53, 4 February 2014 (UTC)
I have always found Q172668 especially amusing. --Jakob (talk) 19:35, 4 February 2014 (UTC)
There's a great(*) helles (Q261105) from there(**), called Fucking Hell (Q5507019).
(*: I did not taste it, but I assume it's great.)
(**: It's not actually from there. They just say so, so they can use the name.) --YMS (talk) 19:42, 4 February 2014 (UTC)
This politician never made an international career, but I guess her name would have been a great help. -- Lavallen (talk) 20:11, 4 February 2014 (UTC)
Wikimedians,:D --Nizil Shah (talk) 19:36, 9 February 2014 (UTC)

Played by ... in work ?

. existential quantification (Q773483) Punknown such that Punknown instance of (P31) Wikidata qualifier (Q15720608) logical conjunction (Q191081)

< Invisible Woman (Q510450)     > performer (P175)   < Jessica Alba (Q44077)     >
Punknown search < Q224130 >


In english, do we have a qualifier to apply to say in which movie Jessica Alba did played was the invisible Woman ?

PS: No, we can't yet speak just using items. To bad we can't create a real international Project Chat like that :)

TomT0m (talk) 19:49, 9 February 2014 (UTC)

Using performer (P175) for characters is incorrect. The way to indicate what actor played what part in what movie is by using cast member (P161) with character role (P453) as a qualifier, which was created specifically for this purpose. I've added the mentioned character role to Fantastic Four (Q224130), to show an example. --Yair rand (talk) 20:31, 9 February 2014 (UTC)
I was confused by the french label interprète, which is a word used both when a singer sings a song and an actor plays some character in a play. I guess we could extend the scope of the relation as it's not really something different, it's some work designed for a performance played by a person or a group of people. TomT0m (talk) 20:38, 9 February 2014 (UTC)

Translating given names

Preface: I'm new here but have been editing at English Wikipedia for awhile (UT:AjaxSmack) so if this is dealt with somewhere else, please say. I got here from en:Richard because of some weird interwiki links and made some edits here as a result.

My question is, how does Wikidata deal with forenames with different forms in different languages and the multiple Wikipedia pages that result? English has pages including:

Other languages have similar complexity. E.g., French fr:Richard and fr:Richárd (for the Hungarian [sic] name), or Russian with ru:Рихард, ru:Ричард, and ru:Ришар, none of which seems to be the "default" name.

The relevant Wikidata page seems to be Q1249148 ("Ryszard"). But what about Q14626242 ("Richard") where two of the links were stranded? AjaxSmack (talk) 23:45, 9 February 2014 (UTC)

@AjaxSmack: this is a common problem with disambig pages and pages ("articles") about names (given names, surnames or both combined). links are often mixed a lot, i think because of the long history of storing interwiki links at so many locations, and because users often linked these pages differently on different wikis. I will see what i can do in this case. Holger1959 (talk) 23:55, 9 February 2014 (UTC)
I notice that you farmed out some of the names to new items (e.g., Ryszard to Q15720963 ["Ryszard"] and Ricardo to Q15720871 ["Ricardo"]). The problem with that is it breaks the Wikipedia links, i.e. now the the language bar on en:Richard does not link to pl:Ryszard, es:Ricardo, &c. That is the problem I was referring to. :En:Richard and es:Ricardo are obviously equivalent articles and should link to each other but this is complicated by the existence of en:Ricardo and es:Richard. Should I just override it with manual entries in Wikipedia? AjaxSmack (talk) 04:13, 10 February 2014 (UTC)
yes, you can make local links on Wikipedia if it makes sense for you. they override interwiki links from Wikidata, see en:Help:Interlanguage_links#Local_links and en:Wikipedia:Wikidata for some help. And if you find interwiki conflicts you can use Wikidata:Interwiki conflicts. Holger1959 (talk) 05:59, 10 February 2014 (UTC)

Case study: inhabitant (Q22947)

Just a thought about the use of items and Basic membership properties and a meal to thinking :

Can we use this example item in a statement ? somebody is an inhabitant (Q22947) of a place if he lives in that place. Hence the item corresponds to a relation beetween someone and a place. If we say someone, for example, is an inhabitant, it does not make much sense without giving a place he lives in, except if we say a nomad lives nowhere, so humanity would be divided into <nomads> and <inhabitants>.

If we create items like <Paris inhabitants>, of which all inhabitants would be implied to leave (or have lived) in <Paris>, we kind of recreated the relation. Could we say meaningfully that it is a subclass of <inhabitant> ?

There is another possibility (I don't like it): we could use <someone> instance of (P31) <inhabitant> [ of <Paris ] some kind of of qualifier.

TomT0m (talk) 19:29, 5 February 2014 (UTC)

I think 'Alice residence Paris' would be a better way to capture this information. Explicitly stating 'Alice instance of inhabitant of Paris' on the item for Alice treats 'instance of' as a catch-all property, which I think is a bad practice. Information like residence, occupation, date of birth, place of birth, etc. could all potentially be modeled with P31, but I think P31 should generally be used to provide a single preferred classification for a subject. Other properties like 'residence' should be put into conventional properties like residence (P551), not instance of (P31). Emw (talk) 20:16, 8 February 2014 (UTC)
This was not the main problem I wanted to try to address, but it's an exercise, so it's also good to think about that :) I don't agree with you for at least two reasons :
  1. P31 is not a property like any other else in OWL, as you know. It is used together with subclass of and class definitions to precise the properties of the instances. Which means an instance of some class has some property given by the class definition. It's not the same to say that someone is a tennis player and saying that someone is an instance of tennis player for example, beeing a tennis player implies some properties and some values of some properties : a professional tennis player probably have some ATP rank. Similarly an inhabitant of Paris may have some local implied property as well (I don't know if that's actually the case.) This particularities might be modeled as an OWL formula that define our class, and saying that our instance is an instance of that class implies some things on this instances.
  2. It does not seem very easy to find a practical rule about the class something is supposed to belong to. It's a giant rule of thumb that is prone to discussion, disagreements, and to arbitrary rules not well thought. In contrast the first point could give some clues about this : if a class, like inhabitant of Paris, is really simply defined as lives in <Paris> and nothing more, it does not add any information more than trivial. In contrast, if every habitant of Paris have to (totally fictional) traditionaly take part in some competition, and that he has a public rank in that competition, then saying someone is an instance of Paris inhabitant implies not only that he lives in <Paris>, but also that he has (or should have) another statement, which is a clue for a missing information.
With that in mind, it become (uselessly in my mind) restrictive to think that someone has just a single class he naturally belongs to. TomT0m (talk) 21:06, 8 February 2014 (UTC)
TomT0m, explicit P31 statements are not needed in the cases you describe. Note that 'residence Paris' can be used to implicitly assign any subject to the class 'inhabitant of Paris' by the following OWL expression:

<!-- Example 1. residence (P551): Paris -> instance of (P31): inhabitant of Paris -->
<owl:Class rdf:about="inhabitant of Paris">
           <owl:onProperty rdf:resource="residence" />
           <owl:hasValue rdf:resource="Paris" />
This would eliminate the need for redundant claims like 'instance of: inhabitant of Paris' when conventional claims like 'residence: Paris' exist on an item. Other properties like 'occupation' would benefit much more by using the approach described above. Clearly, though, manually encoding such expressions would be tedious. Perhaps we could have a dynamic class expression like the following:

<!-- Example 2. occupation (P106): $occupation -> instance of (P31): $occupation -->
<owl:Class rdf:about="$occupation">
           <owl:onProperty rdf:resource="occupation" />
           <owl:hasValue rdf:resource="$occupation" />
Another variation is below. It would implicitly make subjects of the claim 'alma mater: $school' instances of the class '$school alumnus':

<!-- Example 3. educated at (P69): $school -> instance of (P31): $school alumnus -->
<owl:Class rdf:about="$school alumnus">
           <owl:onProperty rdf:resource="alma mater" />
           <owl:hasValue rdf:resource="$school" />
Example 1 is directly supported in OWL 2 DL. Examples 2 and 3 are not directly supported, but they are well-defined and easily translatable into the format of Example 1. Examples 2 and 3 could be stored as property statements and translated into OWL by an export script. With those items being inferred instances of certain classes as outlined above, further restrictions like "all professional tennis players must have some ATP rank" can be implemented without a bunch of extraneous P31 statements. Emw (talk) 22:11, 9 February 2014 (UTC)
Looks to me you are looking for metamodeling. The class expressions you are looking for with $variables can probably be encoded into a class of the class restriction on the inhabitant of <somewhere> statement, or something like that, without looking more. Anyway, about redundancy, I think it's not a bas thing to have redundancy of Wikidata and explicitely name the class (It's late but I did not understood to what you wanted to attach your class expression, do you want to express them on wikidata ? then the easiest way is to attach them to an item and ... name that item.) as Wikidata is a moving project prone to errors and vandalism. I think redundancy in that case can help to make the database more robust to vandalism, errors and so on. Anyway class expression in Manchester Syntax are way more consise and easy to write and read :) There must also be parsers, so write them in Manchester syntax and translate them into statements is surely not a problem. TomT0m (talk) 22:46, 9 February 2014 (UTC)
TomT0m, the examples above do not require metamodeling any more than P31 or P279 already do. They are class expressions, and do not necessarily require treating classes as individuals. Of course, we may want to invoke metamodeling for other purposes on the same items, but it is not strictly required here.
The point of my previous post was to demonstrate how claims like "instance of: inhabitant of Paris" do not need to be explicitly stated on items like Coco Chanel (Q45661); that we could capture Coco's membership in the class 'inhabitant of Paris' with the claim 'Coco Chanel residence Paris' by making a statement in the class 'inhabitant of Paris'. The redundancy of putting such expressions on each applicable class might not be the most space-efficient implementation, but it's drastically less redundant than explicitly applying 'instance of: inhabitant of $place' to all individuals we want to make such instances of, as you seemed to have been suggesting.
I agree that Manchester Syntax (MS) is a much more succinct and human readable way to talk about class expressions. Here is how the first example above appears in MS:

// Example 1 in Manchester Syntax.  Clearly more readable than RDF/XML.
Class: inhabitant of Paris
       residence value Paris
How do we capture expressions like that in Wikidata statements? It's an n-ary statement, so qualifiers are natural candidates. Qualifiers will not be queryable in the foreseeable future, but that doesn't seem relevant here because the inference required for the examples above is something done by reasoners like HermiT (built into Protege), not directly by query engines like SPARQL.
One option might be to encode property restrictions by using a special property 'equivalent class' (that has the semantics of owl:equivalentClass), which takes values like 'value' (owl:hasValue), 'some' (owl:someValuesFrom, i.e. ), 'only' (owl:allValuesFrom, i.e. ), 'minimum' (owl:minCardinality), 'exactly' (owl:cardinality) and 'maximum' (owl:maxCardinality). For example:

// Example 1 in existing Wikidata UI syntax.  Requires special treatment in RDF export.
inhabitant of Paris (Qx) (a hypothetical item)
    equivalent class (Px): value (Qy) (a statement)
        residence (P551): Paris (Q90) (a qualifier on the above statement)
This would be a succinct way to state "all items like have the claim 'residence: Paris' are instances of the class 'inhabitant of Paris'". Importantly, 'equivalent class' would not be a conventional property and 'value' etc. would not be conventional values, and qualifiers used for statements involving them would not be reified in an RDF export. Instead, such statements be converted to class expressions in the RDF/XML format of Example 1. Emw (talk) 02:38, 10 February 2014 (UTC)
@Emw: re, several things:
  1. for metamodelling, I was refering to your dynamic class expressions. It looks like a lot like a Template in C++ or Generic in Java or C# in programming. The rationale behind this was to use a meta class as a pattern to define a set of classes who have a parameter, something like alumnusof[University], with University as a variable, and to define the properties of any alumni in the metaclass as a template. But we're starting to be a little too much complex and this might be out of scope of OWL2 metamodeling, with a little more thinking.
  2. For redundancy : stating explicitely that an individual is an instance of a class defined by a complex exression can put more robustness to change in the database. For example imagine we defined the class Paris inhabitant as individual that have a lives in <Paris> statement. Now a vandal changes this to lives in <New York>. The change would be unoticed, except if we have a statement that explicitely states it must fulfill the class expression predicate. That's how the redundancy, used as constraint definitions, can be used.
  3. Related to that : If we want to infer (logically) that any inhabitant of Paris has some more properties, I think we need not only the expression

Class: inhabitant of Paris

       residence value Paris

but also a second one : Class: inhabitant of Paris Special properties

       hasValue ParisResidentNumber

and a statement that says that <inhabitant of Paris Special properties> and <inhabitant of Paris> are equivalent classes. That way, we have some kind of "if ... then ..." expression : if it is an inhabitant of Paris, then it must have a Paris Resident Number. We might have to do this because if we just define one class which says that an inhabitant of Paris lives in Paris and have a redident number, if the database has no residence number for an inhabitant of Paris he will simply be infered not to be in the inhabitant of Paris class, and the database will remain coherent and we will not know that the information is missing. TomT0m (talk) 17:33, 10 February 2014 (UTC)

Confusion over topic

Can someone help me sort out:

  • Category:Emergency medical services
  • Prehospital care
  • Emergency medical services

The three seem to be mixed up. Evrik (talk) 21:40, 7 February 2014 (UTC)

@Evrik: presumably you talk about three items you edited in january:
i don't know what should be fixed there. maybe someone else can have a look? Holger1959 (talk) 16:58, 8 February 2014 (UTC)
It seems that across all the wikis, the three subjects are mixed up and that the three entries on wikidata are equally confused. I stopped editing it when I realized I couldn't sort it out. Evrik (talk) 16:34, 10 February 2014 (UTC)
I would suggest that you submit a request at WD:IC. That's a slightly more permanent place for questions like this. --Izno (talk) 16:46, 10 February 2014 (UTC)

Complex demographics

The property population (P1082) can be used to show the number of people in an area, but how does one show further demographic information, such as how many people from a particular ethnic, linguistic, religious, economic, or age group are in a particular area? And how much of this type of data should be included in the first place?

Assuming we do want to have this kind of data, we could do much of it with qualifiers to population (P1082). Perhaps we could use the existing sex or gender (P21), native language (P103), ethnic group (P172), religion (P140), etc. with a few added for other types of groups. Alternatively, we could add this data to the items for the ethnic groups, languages, and so on, and have a qualifier indicate what area is being referred to. number of speakers (P1098) was already created for this purpose for languages, but does not have an associated qualifier property yet. Presumably, if this option in not chosen, the property could be deleted. Another option would be to ask the devs to add some system for piling up data tables, and add those to either the item for the place, the group, the relevant census/poll/estimate, or independently.

A lot of this kind of data is likely to be very useful, but we might need to draw the line somewhere. While it would certainly be useful to have data on how many people of a particular major ethnicity or language group are in a particular country (plenty of Wikipedias could use this in infoboxes and charts, for instance), it might not be necessary to include that 75±2 male native English speakers aged 15-24 years old in New Brunswick live in homes where Mi'kmaq (Q13321) is the language most often spoken at home according to the Canada 2006 Census (Q5029298). I don't know what kinds of technical limitations we have for items, from either the perspectives of Wikidata or internal (Wikimedian) or external re-users of data. If we don't place any sort of limits on this, we might have tens of thousands of statements to an item, which might make it difficult to edit items and/or difficult for Lua templates to access the needed data. I think we should thoroughly hammer out a policy of what kinds of demographic data to include and how to include it, before we start hauling in thousands or millions of statements from censuses. Thoughts? --Yair rand (talk) 00:40, 10 February 2014 (UTC)

  • In principle I would support any basic demographic data that has reliable sources. However, there is the problem of item size. I do often envision items with hundreds or thousands of statements from which a full article can be written entirely using Wikidata. Unfortunately, items with more than a few statements load very slowly for me. Perhaps the code for statements can be modified so that they are simpler and will take less time to load? Then more statements can be added to items without causing browsers to crash. I apologize if it sounds like I'm spouting nonsense --Jakob (talk) 02:02, 10 February 2014 (UTC)
  • We have to go step by step: I think we have to focus first to provide one value for each administrative division about the population with a reference. Then you can do the same for different years or periods. Just doing that will take some time. For more complex data sets we have to think to a new datatype like table but I think we have to stop now at a simple description and try 1) to provide reliable data and 2) to be systematic. For data used in graphics we should to think about new tools but we have already a lot of to complete the current structure. Think that we are in the second phase of wikidata development which focus on infoboxes so I am not sure that the information you want to add can be added easily in the current infoboxes. Snipre (talk) 14:51, 10 February 2014 (UTC)

Question about P107: enwp used it, so now what?

Hi all, I left a question about what we should in place of P107 in a major English Wikipedia template here. Thanks for your ideas. -- Phoebe (talk) 06:50, 10 February 2014 (UTC)

@Phoebe: You should try to query if there're sitelink to Wikivoyage. voy:zh:Module:RelatedSites is an example.--GZWDer (talk) 09:50, 10 February 2014 (UTC)
@GZWDer: thanks for the example! I wasn't sure how this would be expressed. Right now the template also shows redlinks/search, which is actually kind of nice in an encouraging-editing sense, but I guess we will have to give up on this. p.s. lots more discussion on the talkpage! -- Phoebe (talk) 16:16, 10 February 2014 (UTC)

Showcase items

First, who is it who approves showcase item nominations?

Second, I have come up with an idea regarding showcase items. Instead of having on the main page:

See Wikidata in action: View the item about Wikipedia, the free encyclopedia.

How about having something like:

See Wikidata in action: View Q12345678, the latest showcase item.

Since showcase items are recognized as good items, this seems like it would make sense. Also, this would provide some variety. --Jakob (talk) 14:47, 10 February 2014 (UTC)

No one is responsible for approving showcase items. When I have time, Lydia and I discuss certain items for showcase to display in the weekly summaries which are then usually moved up. I have not actually looked at this at all recent but ultimately if community members want to approve things; there is an approved section where I myself would like users to place things and then I'll move them up during the next summary to ensure the whole point of why we started it is fulfilled. But ultimately, there is nothing surrounds who can do what with it. Community consensus exists around but the reason it exists now and as is simply to promote items in the weekly summaries. John F. Lewis (talk) 14:57, 10 February 2014 (UTC)

interleaved sequences

Hi, this item Private Parts and Pieces II: Back to the Pavilion (Q7246127) is a music album. It belongs to two sequences of albums : the discograhia of its author, and the album it is a sequel to. So if we want to both model these sequences with the precedeed by and followed by properties we have to put a qualifier. I propose to create the in sequence qualifier. part of may be OK though, but it has the same problem than using instance of (P31) as a qualifier. TomT0m (talk) 20:25, 10 February 2014 (UTC)


I have got open an RFC for a giudeline as discussion above [5] we need a giudeline for millions of items, therefore would require the participation of many people as possible Wikidata:Requests_for_comment/Administative_divisions_and_populated_places--Rippitippi (talk) 21:18, 10 February 2014 (UTC)

Taxa causing constraint violations for subclasses

I get the impression that the classification of species uses their on taxon system rather than P279 subclasses. That's fine, but it means we get constraint violations at Wikidata:Database reports/Constraint violations/P279 and Wikidata:Database reports/Constraint violations/P31 each time a item is an instance of an animal (like Koko (Q1348219) -P31-> Gorilla (Q36611)) or any recognized group of animals being a subclass of its species. Can we apply a P279 subclass to species pages to get rid of the constraint violations? This P279 classification doesn't have to be as detailed as the existing taxonomic classification, I'm thinking that subclass of animal and subclass of plant would be good enough. --Arctic.gnome (talk) 23:31, 30 January 2014 (UTC)

In my opinion subclass of (P279) should get the same value as parent taxon. --Tobias1984 (talk) 06:59, 31 January 2014 (UTC)
The constraint on instance of (P31) makes no sense and should be removed. We discussed the semantics of the properties and items related to classes and instances, at length, here. Being the object of instance of (P31) is sufficient to make an item a class, it shouldn't need a subclass of (P279) relation. Klortho (talk) 07:24, 31 January 2014 (UTC)
Alternatively, we could stop using a domain-specific language to describe taxonomic items. But nah, that would be crazy!... --Izno (talk) 20:05, 31 January 2014 (UTC)
I would tend to agree with Tobias. On taxonomic items a subclass of statement should be added using the same value as parent taxon; ditto for P31 and taxon rank (and subsequent removal of P31 taxon where used). --Izno (talk) 20:05, 31 January 2014 (UTC)
In my opinion instance of (P31) = taxon is not the best we can do as far as structured data goes. If we say that "Animal animalis" is an instance of "species" and "species" is in the subclass of (P279)-tree of taxon, then why should we settle for something as unspecific as instance of (P31) = taxon. --Tobias1984 (talk) 20:17, 31 January 2014 (UTC)
I agree, which is why I said what I said. :) Of course, then we have cases like monotypic taxon, which I still haven't decided whether it's better to say instance of monotypic or instance of the taxa. Probably some combination of the two, or maybe qualified with the specifically property that is still at property creation requests. --Izno (talk) 20:23, 31 January 2014 (UTC)
I just thought I would say it again, because I didn't like the idea of a bot adding "instance of = taxon" to millions of taxa :). In any case some of the properties we work with now will turn out to be scaffolding we use to build the database. As Wikidata becomes more intelligent we can probably get rid of a lot of properties. Now we still need very specific properties and their constraint violations to manage the data. --Tobias1984 (talk) 20:33, 31 January 2014 (UTC)
Are there any subclasses of biota (Q2382443) that are not instances of taxon? Can there be? If so, P31 'taxon' seems necessary. If not, then perhaps it is less necessary than had been thought. Emw (talk) 04:49, 1 February 2014 (UTC)Sorry, but
there are several. Currently hybrids and vernacular groups of biota (e.g. monkeys) come in my mind which we already have. We also thinking of distincting fossils as subclass of taxon. But is not even FC Bayern Munich II (Q994701) at the very end a subclass of the taxon (group of animals) human? :-)  — Felix Reimann (talk) 08:27, 1 February 2014 (UTC)
@Izno: I don't understand your reasoning wrt. Monotypic taxons. They are taxon, so monotypics taxons are a subset of all taxons, hence <Monotypic taxon> subclass of (P279) <taxon>, which have the property of beeing monotypic. The definition of monotipic is a little more complicated to express correctly here, but it should be possible :) in OWL :) TomT0m (talk) 15:16, 1 February 2014 (UTC)
You probably just caught me being unintelligible. :) As it stands, let's assumme that there are cases where we would replace P31 = taxon with P31 = valueOftaxon_rank. That covers most taxa. However, there are taxa which currently have P31 = monotypic taxon. Do you simply add P31 = valueOftaxon_rank in that case? Or is there a more elegant way to handle that claim? --Izno (talk) 03:44, 2 February 2014 (UTC)
Tobias, I agree that subclass of (P279) should get the same value as parent taxon (P171) where P171 is used, if P171 remains. It has been suggested that P171 can be made a subproperty of P279 (i.e., rdfs:subClassOf). However, doing so would be invalid in OWL 2 DL and to my understanding make querying and inference undecidable, so I don't think that's a viable option. There are long related conversations here and here. Emw (talk) 04:40, 1 February 2014 (UTC)
There are lots of cases where it is useful (even necessary) to use something like "instance of Arbor magnificus" to indicate the item is not a member of Arbor magnificus, but has some relationship with Arbor magnificus. This is not perfect but not much on Wikidata is. - Brya (talk) 05:31, 1 February 2014 (UTC)
Brya, could you provide an example? At first glance and without much context, that use of 'instance of' seems odd. P31 implies the subject is an instance of the class denoted by the object. So if a subject is an instance of a taxon 'Arbor magnificus', then it would be a particular organism, e.g. a tree that has a specific geographic coordinates. Emw (talk) 06:06, 1 February 2014 (UTC)
Well, in practice "instance of" is a catch-all bin of everything that does not belong elsewhere, and certainly is not a subclass of. An example are Durian fruits; these are produced by several, but not all, species of Durio, mostly by Durio zibethinus. The main thing is to make sure these fruits are kept out of any taxobox, so the fruits are both an instance of Durio and an instance of Durio zibethinus. Not pretty, but the best possible. - Brya (talk) 07:22, 1 February 2014 (UTC)
Both, instance of (P31) and subclass of are just wrong in this case. Use part of (P361).  — Felix Reimann (talk) 08:01, 1 February 2014 (UTC)
I suggest you take it up with Felix Reimann who said this was the only approach possible. - Brya (talk) 08:43, 1 February 2014 (UTC)
Did you mean to reply to Felix there?... --Izno (talk) 03:44, 2 February 2014 (UTC)
Affirmative. - Brya (talk) 17:55, 2 February 2014 (UTC)
Emw, why is it not an option? We need a special handling for the RDF export of instance of and subclass of nonetheless to comply to RDF. Then we could also export P171 (formally marked as a subproperty of subclass of here at Wikidata) as subclass of. It is ok for me to loose this distinction at the export to if RDF if RDF does not support it. But why should we not support it? Why is the export to RDF more important than usability, problem specific models, and the needs of those who really try to get this bunch of data in a shape to be used at our clients, the Wikipedias and friends?  — Felix Reimann (talk) 08:14, 1 February 2014 (UTC)
Felix, it is necessary to comply with OWL DL, the subset of RDF that is decidable. As I understand it, if Wikidata is not valid OWL DL, then our queries are not guaranteed to terminate. If it is, then our queries would terminate, and generally have well-optimized implementations in query engines and reasoners. Decidability is widely regarded as an essential computational property of large knowledgebases. There is a trade-off between expressiveness and computability, this is one example. Parent taxon can be transitive without being a subproperty of 'subclass of'. Emw (talk) 14:52, 1 February 2014 (UTC)
Emw, you said, "P171 ... a subproperty of P279 ... would be invalid in OWL 2 DL". You have said this kind of thing before in other discussions, and I remain firmly unconvinced. I would really like to explore this issue, because I think it is important. Likewise, making subproperties of "instance of". I would suggest the burden of proof is with you, still, but I will go back and review those references that you pointed to on other threads. Perhaps we could send a message to public-lod, or enlist some other Semantic Web experts, to help us with this question. Klortho (talk) 00:39, 2 February 2014 (UTC)
Let me add why I am unconvinced: because it seems to me, that defining P171 to be a subproperty of P279 is the same thing as replacing every instance of P171 with two other properties, P279, and another property that has the extra, added semantics that P171 has in addition to it's "subproperty of" semantics. If the latter graph is decidable, then I can't see how the former (with its subproperty of definition) could be undecideable. Klortho (talk) 01:17, 2 February 2014 (UTC)
OWL1 full is undecidable because of the ability to express too powerful things with metamodelling, like beeing able to build an infinite chain of subclasses by expressing that the subclass of values must themselves have a subclass of property amongs other things. To prevent that, the decidable OWL2 with meta modeling adds constraint on the ability to make statements on fundamental properties. I guess by making a subproperty of subclass of (if that's even possible), to be OWL2 compliant we would have to ensure the subproperty have the same restrictions at least. TomT0m (talk) 17:22, 2 February 2014 (UTC)
Our queries will not terminate? Why? First, I do not believe this. Really, I do not see why joining two properties might have negative impact on computability. Second, if this would be the case it is a problem of our developers. They will either find a way to have queries terminating or need to restructure *everything*.  — Felix Reimann (talk) 16:43, 2 February 2014 (UTC)
  • Subproperty implementation is at least, if it happens, will not be in the forseable future and is not in this year roadmap. I guess we will have to use simple queries for a while. The taxon items marked instance of (P31) taxon will be enough and usable with simple query for sure. Then we will be able to extract a taxon tree quite easily and work with subclass of (P279) with generic tools with no difference than with parent taxon, benefiting the same tools than the whole project. TomT0m (talk) 17:22, 2 February 2014 (UTC)
  • Klortho, Felix, the OWL 2 DL-validity of creating subproperties of 'instance of' and 'subclass of' was discussed a few weeks ago, ending up at Wikidata:Project_chat/Archive/2014/01#Motik_on_metamodeling. In the paper discussed there, On the Properties of Metamodeling in OWL, Motik concludes that "the style of metamodeling adopted in OWL Full leads to the undecidability of basic reasoning problems, because it allows us to state axioms about the built-in vocabulary." Built-in vocabulary includes rdf:type and rdfs:subClassOf. Motik's paper is the basis for metamodeling in OWL 2 DL.
This restriction is expressed in the OWL 2 structural specification in the section on object properties when it notes that "IRIs from the reserved vocabulary other than owl:topDataProperty and owl:bottomDataProperty MUST NOT be used to identify object properties in an OWL 2 DL ontology." The same restriction applies to data properties. Wikidata properties with datatype 'item' are object properties; other properties are data properties. These things indicate that creating subproperties of rdf:type and rdfs:subClassOf is more than a trivial matter of, say, replacing all 'X parent taxon Y' claims with 'X rdfs:subClassOf Y' and 'rdf:type taxon'.
I am aware of two approaches for handling 'parent taxon' in high-profile structured vocabularies, but neither involves making it a subproperty of 'subclass of'. The first approach, used in the UniProt ontology, uses rdfs:subClassOf to capture 'parent taxon' relations. See its entry for dog: The second approach, used in Darwin Core, uses a 'parentNameUsage' property as described in, which is marked as a 'property'. (Unfortunately, I can't find where that property is declared in the Darwin Core RDF.)
Felix has raised concerns about how to distinguish subclass relations in different taxonomies. For example, in biological taxonomy, house cat (Q146) is a subclass of Felis silvestris (Q43576). Let's ignore the fact that feral cat (Q2404562) is a subclass of cat but not pet, and posit for the sake of discussion that all instances of house cat (Q146) are also instances of pet (Q39201) and thus house cat (Q146) is subclass of pet (Q39201). When presented with the claims 'cat subclass of wildcat' and 'cat subclass of pet', how do we go "up the chain" in one the organismic taxonomy but not the pet taxonomy?
The solution TomT0m has suggested for a while seems like a feasible way to address Felix's concern. In brief, query for the subsumption hierarchy of house cat (Q146) where 'instance of taxon' holds. This is essentially what making 'parent taxon' a subproperty of 'subclass of' would do, but it does so in a way that is valid in OWL 2 DL. Emw (talk) 21:47, 2 February 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Hi, Emw, thanks for your thoughtful reply. I dropped the ball on the conversation that you linked to, the last time this came up, because I was unconvinced then, but didn't really have time to research it and respond.

I skimmed over the Motik paper, and there is this crucial quote that I see you saw, but you didn't copy here: "The proof of Lemma 1 suggests the causes for undecidability. Namely, OWL Full not only allows us to treat concepts as individuals, but it allows the built-in vocabulary (the resources such as owl:allValuesFrom) to be used as individuals in axioms." Note that a triple "foo rdfs:subPropertyOf rdf:type" does not treat "rdf:type" as an individual; it treats it as a property.

OWL Web Ontology Language Reference, Appendix E, Rules of Thumb for OWL DL ontologies, summarizes the restrictions like this: "Don't mess with the vocabulary: The built-in properties and classes should not be redefined. In general this means that things in the OWL, RDF or RDFS namespaces should not appear as subjects of triples." Note that a triple "foo rdfs:subPropertyOf rdf:type" does not use "rdf:type" as the subject of a triple.

Regarding Ian Horrock's email, I think you did not read it carefully enough. He is explicitly stating that the reason for the restriction is not that it would make OWL DL undecideable, which is what you have repeated many times. It is about "separating the syntax of the language from the domain of discourse". In our case, both the Wikidata "instance of" property, and any property that we would decide to make a subproperty of it, would be on a par. I'm not quite sure exactly how Horrock defines these, but Motik also talks about this kind of separation, on page 2. He describes the class hierarchy "Eagle subclassOf Bird" as part of the conceptual model, and "Harry type Eagle" as being the data. Per that description, I'd say both instance of (P31) and any property that we make a subproperty of it, would be part of the conceptual model.

I think you are right that these relations are prohibited in OWL DL, in the OWL Spec, section 5.3, notwithstanding the comment that I made on your question on But nevertheless, I don't think it's because it makes the language undecideable. Just as we can add punning (also not allowed in OWL DL), why couldn't we allow these? I think they would make things a lot more intuitive and simple.

Above, you wrote, "... more than a trivial matter of, say, replacing all 'X parent taxon Y' claims with 'X rdfs:subClassOf Y' and 'rdf:type taxon'." That is not what I was suggesting. That translation would include a kind of punning that would make things complicated. I would say that 'X parent-taxon Y' would be replaced with 'X rdfs:subClassOf Y' and 'X parent-taxon-ns Y', where "parent-taxon-ns" is another relation that is not defined to be a subproperty of subclass, but that encodes the additional semantics of "taxon". So, the statement 'X parent taxon Y' means, in plain English, that X is a sublass of Y by virtue of its being a subtaxon. To close the loop here, note that we would not be defining anything to be a "rdfs:subPropertyOf rdf:type". That is RDF/OWL vocabulary, and we'd be defining things according to the Wikidata model. In the RDF export, we could translate the wikidata model into RDF per the scheme I just described. Klortho (talk) 04:59, 3 February 2014 (UTC)

Mmm looks like there is a flow in your reasoning. The easiest to say something has a semantic of some class of things, like taxon, in OWL, is to make it an instance of taxon (or an instance of taxon), with the taxon semantics associated with the class taxon. Maybe using parent taxon would imply the parent is also a taxon if its range is taxon, and hence would be consistent, but in that case it would be redundant, and this is a false opposition, we could live with both. I thin instance of (P31) <taxon> is a fair and simple property to use, and its general nature gives a fair way to qury the typa without domain knowledge, so it's anyway useful and something thac is worth teatching community wise. So ideally I think it should be put on any item. ––––
At first I thought it would be redundant to give instance of and subclass of the same values as taxon rank and parent taxon, respectively. But after reading this discussion, I think it makes sense. The taxa structure can reflect scientific consensus exactly how it is needed for data analysis, while the subclass system can reflect the scientific consensus alongside unofficial non-taxa groups like "flying animals" or "European lizards". --Arctic.gnome (talk) 01:00, 2 February 2014 (UTC)

I wonder if there is any chance that we can wrap up this discussion with a reasonable conclusion (meaning, of course, the conclusion that I want ;) ). To sum up my point of view:

  • The constraint on instance of (P31) should be removed. It should not be necessary for every class to have a subclass of (P279) relation. It is sufficient that an item be the object of an instance of (P31) statement to make it a class.
  • It is okay to define a property P to be a "subproperty" of subclass of (P279). Meaning, that for any two items C1 and C2, if (C1 → P → C2) then (C1 → subclass of (P279) → C2) can be inferred.
  • This is great, because it will allow us to define class hierarchies that have extra semantics. For example, parent taxon (P171) defines a particular class hierarchy of biological taxonomy. So, by specifying one statement on, for example, Gorilla (Q36611), we know that it is a class, we know what its parent is in this particular class hierarchy, and we know that this class is an instance of the classes of biological taxonomies.
  • That this does not make our data model undecidable. What I just described is another instance of the kind of punning that we have agreed in other discussions is fine (treating Gorilla (Q36611) as both a class and an individual). It is not allowed in OWL DL, but, {OWL DL + this kind of punning} is not undecidable.
  • Finally (and this point is a little redundant) we don't need to define both parent taxon (P171) and subclass of (P279) for every taxonomic class, both pointing to the same thing. Thinking about this last point should make it clear: imagine that we did specify that for every statement (T1 → parent taxon (P171) → T2), we require that there also be a statement (T1 → subclass of (P279) → T2). How is that different from merely specifying that parent taxon (P171) has this semantic meaning?

Klortho (talk) 02:49, 5 February 2014 (UTC)

Not OK with this. Inferences are far out of sight, independantly from the subclass of subproperty, which imply to be consistent with the class tools we will develop it will be far more easy to make them explicit. It seems to me a small concession as it's a simple bot task. For the tools, I think for example to a simple subclass tree template which would need the top class and the class of subclasses to consider (eg. taxon). As soon as simple query is available. TomT0m (talk) 11:44, 5 February 2014 (UTC)
Why couldn't these class tools be aware of all the properties that are (explicitly) declared to be subproperties of subclass? Klortho (talk) 13:27, 5 February 2014 (UTC)
I'm quite happy with the fact we will be able to make statements about properties, but it's not really possible to give a date for that: TomT0m (talk)
And, I'd also like to know exactly what you're proposing as an alternative: either getting rid of the parent taxon property in favor of subclass, or making the redundant relations (T1 → parent taxon (P171) → T2) and (T1 → subclass of (P279) → T2) on every taxonomic class, or what? Klortho (talk) 13:29, 5 February 2014 (UTC)
Mmm I thought you would already think you would be aware of my propositon because I'm talking about it in every discussions for a while. In a nutshell: mark every taxon as instance of (P31) taxon (Q16521). Use subclass of (P279) in the same way as parent taxon. Query to reconstruct the same tree as with parent taxon (just the son of a node X) : get all the items Y such that <Y> subclass of <X> and <Y> instance of (P31) <taxon>: Optionally keep a redundant parent taxon. Bonuses: replace <taxon> with something else, you get something that works for other domain. Needs just Lua and simple queries. Can optionally be use to model other taxonomic trees in biologic taxonomy by adding other taxon class, like «taxon of the tree buit by this group» or «taxon of the tree buit by this other group» without any additional property, so supports easily a NPOV. TomT0m (talk) 14:04, 5 February 2014 (UTC)
It's reasonable, but still not as good as what I'm proposing, because there's the possibility of ambiguity. You wrote, "Can optionally be use to model other taxonomic trees in biologic taxonomy by adding other taxon class". Now, this is totally hypothetical, and I don't know if it's possible, but what if an individual item belongs to multiple taxonomic trees? Maybe there's a taxonomic family F that one group of taxonomers says belongs to order O1, and another group says belongs to order O2. F would have two `subclass of` relations, `instance of` O1, and `instance of` O2. But there would be no way to know which `subclass of` goes with which taxonomic system. Klortho (talk) 01:14, 6 February 2014 (UTC)
Of course there would be a way, I just gave it. There just would not be a way to do this at first sight, but would need informations about the parent class item. But the problem is no different with the parent taxon single property. That said, as it's a potential project wide property there is no doubt this problem can easily be solved once and for all by putting a little more informations aboou the items used in a statement. TomT0m (talk) 09:48, 7 February 2014 (UTC)
Klortho, when Motik suggests the cause of undecidability is using built-in vocabulary "as individuals in axioms", I don't think he is using the term "individuals" as mutually exclusive with "properties" as you portray it. I think he means "as something other than a predicate in an axiom". Consider how the triple (s, rdfs:subPropertyOf, rdf:type) has 'rdf:type' as its object and uses a property 'rdfs:subPropertyOf' that has 'property' as its range, just as the triple (δ2, owl:onProperty, rdf:type) in assertion 7 in Table 2 of Motik's paper has 'rdf:type' as its object and uses a property 'owl:onProperty' that has 'property' as its range. Note how he refers to exploiting assertions 6-8 immediately below the excerpt you quoted about why OWL Full is undecidable. So, the cause of undecidability seems to be simply when one states axioms "about" the reserved vocabulary, e.g. when one uses 'rdf:type' as something other than a predicate in a triple.
You say "[Horrocks] is explicitly stating that the reason for the restriction is not that it would make OWL DL undecideable, which is what you have repeated many times." It's not exactly clear to me how to parse your statement, but I've never said that Horrocks's statement indicates (s, rdfs:subPropertyOf, rdf:type) is prohibited because it would make OWL DL undecidable. What I have said is exactly what you seem to say I've missed: that "per the quote from Ian Horrocks, the restriction on creating an rdfs:subPropertyOf rdf:type is because it is required to keep the language (OWL DL) in conventional first-order logic (FOL)." When noting a source for my suggestions about rdfs:subPropertyOf rdf:type causing undecidability in OWL, I have referenced Motik, not Horrocks.
You ask "Just as we can add punning (also not allowed in OWL DL), why couldn't we allow these [statements about terms in the reserved vocabulary like rdf:type]?" What do you mean by "OWL DL" -- OWL 1 DL or OWL 2 DL? The latter is the relevant version. OWL 2 DL allows punning, but does not allow statements about terms in the reserved vocabulary. The former is decidable, the latter is undecidable. Those are compelling reasons to allow one and not the other.
They're not the only reasons, though. Domain-specific P279 subproperties also hint of a bad data-modeling smell. The motivation for 'parent taxon' is to be able to get an item's ancestor nodes in zoological taxonomy, but not other taxonomies. This begs a question: how, then, do we get an item's ancestor nodes in other taxonomies? It implies having many domain- or feature-specific subsumption properties, e.g. "parent taxon" (wildcat), "parent organism by diet class" (obligate carnivore), "parent organism by birth mode class" (vivipary), "parent organism by thermoregulation class" (endotherm). Not ideal.
A better solution would be to use P279 sparingly on any given class, to give a single or preferred classification. Information for other features, like, say, 'diet (Px)' or 'mode of birth (Py)' or 'mode of thermoregulation (Pz)' can be captured by conventional properties. The subject of a claim 'diet (Px): meat' can be made a subclass of 'carnivore' by the using the owl:equivalentClass and owl:allValuesFrom constructs to define carnivores as all those things that eat meat. This approach provides a way to build a subclass of (P279) hierarchy with a low child-to-parent degree per node by default -- as most users envision taxonomies -- while supporting a much more complex DAG class hierarchy for users interested in taxonomies organized along less conventional properties like 'diet', 'food class', etc. This approach would work with TomT0m's proposal, which I support. Emw (talk) 01:29, 6 February 2014 (UTC)
User:TomT0m, User:Emw, sorry it has taken me a while to respond. TomT0m, I was wrong when I suggested that your way of modeling the relationships would introduce ambiguity. Emw, you might be right about Motik's paper. I suspect not, but the math is beyond me. I guess the most relevant bit, though, is that declaring subproperties of either rdf:type or rdfs:subPropertyOf is not allowed by OWL 2 DL, and that we would want the RDF export of Wikidata to be within that profile, which would permit the use of more reasoners and other tools.
But, what's motivated me in all of this, and still does, is my feeling that "domain-specific P279 subproperties" smell very nice sometimes. In particular, in this case, "parent taxon" seems perfectly reasonable. You and TomT0m are going to great lengths to redesign the models in more complex ways, but the end effect is, in each case, exactly the same.
So let me back up and try one more time. One crucial point that I overlooked in my arguments above is that we wouldn't be declaring subproperties of anything in the OWL reserved vocabularies. We are modeling things in the Wikidata vocabulary. So if we were to say (assuming properties on properties become available) <parent taxon (P171) "subproperty of" subclass of (P279)>, we would be stating that in the Wikidata vocabulary. How we map that into RDF is the question. TomT0m has suggested, for each pair of items A and B that now have <A parent taxon (P171) B>, we instead use <A instance of (P31) "taxon">, <A subclass of (P279) B>, and <B instance of (P31) "taxon"> (TomT0m, is that right?). This seems silly to me: more complicated and difficult to maintain. Why wouldn't it be possible to do this conversion in the RDF export facility? If the conversion happens before it gets to RDF, then either solution would produce the identical RDF, and so if one is OWL 2 DL compliant, the other would be, too.
Emw, you mention using OWL property restrictions, and in fact, I think that that would be one good way to implement the mapping above in the RDF output. The exporter would transform statements using parent taxon (P171) into RDF triples using a URI like `wikidata:parent_taxon`, and then, rather than explicitly specifying <wikidata:parent_taxon rdfs:subPropertyOf rdfs:subClassOf>, we could include, in the ontology, an equivalent class / property restriction on `wikidata:parent_taxon` that accomplishes the same thing. Would that be within OWL 2 DL?
Emw, I think your argument about "parent organism by diet class", etc., is a bit of a straw man. I agree that subclassing should be done sparingly, but that doesn't mean that properties like "parent taxon" are always a bad idea.
Klortho (talk) 13:16, 11 February 2014 (UTC)
+1. I also do not see, why this should not be possible, as our RDF exporter nonetheless requires special handling for P31 and P279. Let me again add some practical concerns:
  1. You can confuse subclass of easily with subclass, a well known rank in taxonomic classification. Even if this sounds stupid for RDF guys, it also looks stupid for an taxonomist that Vipera berus is subclass of Vipera as the first one is a species and the second one is a genus. And we should try hard to have a high usability for biologists as these guys have the domain knowledge we need to make this database valuable and not another data tomb with much but unused data.
  2. There are currently 28.000 items with P279 versus 114.000 with P171 while we already have 1.533.000 items, where P171 is still missing. All in all, we currently expect ~3 million taxa. Keep the properties separated to enable us to apply a divide and conquer strategy for data quality assurance.
  3. The current tooling does not deliver enough support for this. We are working to get the data in a shape that we can convince Wikipedias to use it. To be honest, the RDF export is of lower priority for me. If somewhen you have powerful reasoners to support our task, we might be easier to convince. Today, WikiDataQuery or the constraint violation reports are working already very well for us.
  4. What happens to all the other feasible ways to classify life? While I asked this already, it seems you do not have a common position. Taxa could be monotypic, fossil, poisonous, able to fly, grouped according to vernacular names, and much more. Shall we use P279 for these additionally (and you will have to click on each and every superclass to find the ones which describe the parent taxa) or do you propose new properties for all these other possible classifications out there?
 — Felix Reimann (talk) 14:27, 11 February 2014 (UTC)
Hi FelixReimann, I'm a little discouraged by your commentary. A monotypic taxon should be maked instance of (P31) <monotypic taxon>, that's not a problem at all. The same for all the taxon type, and every other class, one of the keypoint of my proposal is one solution identical for everyone for all classifications. If you don't understand that, please reread my other comments. TomT0m (talk) 18:13, 11 February 2014 (UTC)
Klortho, I put all the arguments on the table, and I don't see how this would be more difficult to maintain. TomT0m (talk) 18:13, 11 February 2014 (UTC)

FelixReimann Klortho Here is something hard to maintain : Q5986351 is linked to 700 items as genera. Problem : it's a disambig item. A genera property is highly redundant compared to go up to the subclass tree and find an item who is an instance of genera. TomT0m (talk) 18:50, 11 February 2014 (UTC)

TomT0m: It was a common problem that is resolved now. --Succu (talk) 20:54, 11 February 2014 (UTC)
Seen this, duplicate. We can thank the bots :) TomT0m (talk) 21:00, 11 February 2014 (UTC)
Did you? And it's simply a service everybody can use. Of course you have to fix the disambig think first. BTW the "genus property" is a little bit out of date. --Succu (talk) 21:17, 11 February 2014 (UTC)
Yep, put the item and one of the linked item in my watchlist to see what would happen. I did not know there was a tool to move the link, last time I did this I coded a bot to clean a mess :). Finally, yes, the genus property is out of date, and for me genus is a particular case of parent taxon the same way parent taxon is a particular case of subclass of. Just another step to go ... ;) To remove the genus property we have to label a genus as instance of genus, that's all. TomT0m (talk) 21:26, 11 February 2014 (UTC)
Your repeated POV: „To remove the genus property we have to label a genus as instance of genus, that's all“ is not new and not worthy another comment. --Succu (talk) 21:42, 11 February 2014 (UTC)

Is it possible to extract a usable Gazetteer from Wikidata ?

Hi. Can anyone give me pointers as to whether it is possible to extract a useful Gazetteer from Wikidata?

Over at Commons, I'm trying to make accessible a collection of one million free out-of-copyright images the British Library recently dumped on Flickr. (The Mechanical Curator collection). To help with that, I've been building a geographical subject index to the titles of the books the images were scanned from (here), to allow the titles to be browsed by geographical country, or county or region. So, for example, the page for the UK looks like this: Synoptic index, UK and Ireland

What I would like to be able to do is to take say the To-do page for England, extract all the capitalized terms (straightforward enough), and then look them up in a hash to see which ones are potentially geographical, and which UK county they point to; which I can then use to file the book titles in the right place in the geographical list.

Soon there should also be the text from image-level tags from the Flickr image pages too, and it would be nice to be able to scan these for potential geographical hits as well.

I've started by using this Open Gazetteer, but it's rather limited -- at least half the geographic terms in the titles aren't being hit. Wikipedia is much stronger, eg on names of castles and districts and other points of interest.

So I'm wondering:

  • (1) Is it possible in any reasonably straightforward way to extract a Gazetteer of geographical features from Wikidata -- eg to extract all the geographical features in the UK, and the counties in which they are located ? (Or perhaps this has even already been done ?)
  • (2) How comprehensive is Wikidata's holding of this data at the present time? For example, I notice that eg for the village of en:Moniaive in Scotland, the infobox on en-wiki identifies it as being in Dumfries and Galloway (the level of geographical detail I'm looking for), but Q6899864 only notes that it is in the United Kingdom.
Likewise en:Dumfries identifies the town as being in Dumfries and Galloway, but Q652035 only identifies it as being in the administrative-territorial entity of Scotland (and country of United Kingdom, at least until September...)

Thanks in advance, Jheald (talk) 11:19, 10 February 2014 (UTC)

Yes, it is possible and a goal of this project. An automatic way is to show the administrative hierarchy according to located in the administrative territorial entity (P131). Here is the current state of Scotland (Q22): [6]. As you see, the hierarchy is not really in a good shape currently. What we currently have are mainly the results of first automatic imports. I changed your example Q6899864 as what I think it should look like (click up the administrative divisions with P131). -> A lot of work is still to do...  — Felix Reimann (talk) 13:54, 10 February 2014 (UTC)
  1. You can get most items with a country through a query for country (P17). Counties, see #2.
  2. The fidelity of the data in located in the administrative territorial entity (P131) usually is at some sub-country level. The hierarchy as a whole does not have a very large quality. --Izno (talk) 14:22, 10 February 2014 (UTC)
That's really helpful. The recursive tree trick is very neat. Thank you.
So to summarise, if I have it right, the necessary structure seems all to be in place; but the various infoboxes and category listings on the relevant Wikipedias haven't been crawled yet to populate it. But I should watch this space.
Thanks again. All best, Jheald (talk) 23:33, 11 February 2014 (UTC)

Move request help

Can someone please move the page Q5098257 to instead be named Think of the children -- as this is the title for it at en:Think of the children ?

Thank you,

Cirt (talk) 01:56, 12 February 2014 (UTC)

  Done: think of the children (Q5098257). Old label "children's interests" retained as alias. Also used Label Collector to import other aliases. LaddΩ chat ;) 03:02, 12 February 2014 (UTC)
Thanks very much, Laddo (talkcontribslogs), much appreciated! :) — Cirt (talk) 03:29, 12 February 2014 (UTC)

author (P50) <-> work (P800): inverse properties?

At Property talk:P50 it is claimed:

  • If [item A] has author (P50) with value [item B],
  • then [item B] should also have work (P800) with value [item A].

Sounds obvious but notable work (P800) is defined as: "subject's notable scientific work or work of art". If an author has published articles that are used as reference in WP (and therefore have an WD item) they do not necessarily are part of his major works. Imho it would be useful to limit notable work (P800) to the major works of an author, excluding minor articles, 2nd editions, translations etc. Otherwise it will be impossible to use P800 for the en:Template:Infobox writer (parameter "notableworks"). --Kolja21 (talk) 01:16, 12 February 2014 (UTC)

What about using ranking preferred only for major work or a qualifier for the same work ? the infobox could then choose only those preferred statements if you like and we keep the ability to index his works. TomT0m (talk) 02:07, 12 February 2014 (UTC)
No because this will be a nightmare to understand which is the purpose of the rank. For me properties like notable work (P800) are not necessary: this is the job of the queries to provide that kind of lists of items especially if we want to be fair in the choice of items we want to link to another. If we want to continue to use notable work (P800) we have to be exhaustive or we have to delete it because limited lists implies contributors choices and these choices are never based on similar and objectives criteria. Items purpose is not to be a wikipedia article with an nice overview of elements linked to a topic but an storage unit for data and data manipulation should be performed through queries. We are mixing wikipedia article and wikidata item and this is not good. Snipre (talk) 12:53, 12 February 2014 (UTC)
Rank purposes are a nightmare to figure out already. I don't think we are mixng anything though, using ranks or not, in the end, to display datas is always an editorial choice from projects. TomT0m (talk)
This inverse constraint has been introduced by you once. I shared the concerns you're expressing now from the beginning, but I was too lazy to start a discussion, especially as I also quite share Snipre's point of view: Most inverse properties should not have to be defined manually, but automatically extracted from the data of one of the items, and whether we set a certain statement or not should not be based on personal judgement as far as this is possible. --YMS (talk) 13:12, 12 February 2014 (UTC)
@YMS: Good to know^^ I've reverted my edit till the end of the discussion. --Kolja21 (talk) 19:44, 12 February 2014 (UTC)
YMS, Snipre. This would be true if Wikidata was a traditional bacend with strong integrity constrants or constraints maintained by the client software. This is not the case. Anybody can access the database and break the data consistincy or remove a legitimate claim. In a kind of environment like that I will advocate that redundacy + integrity reports is a ggod thing. This could help to stop claim removal vandalisms here with the symmetric constaint, as a watchlist change can easyly be missed. TomT0m (talk) 13:25, 12 February 2014 (UTC)
First the problem you pointed is not relevant only for reverse properties so the solution of having redundancy for some properties and not for others is not a good one. Then the reverse properties add new problems so if you solve one and you create a new one at the same time I don't see an improvement. I won't discuss the existence of these reverse properties but I don't agree with a partial use of them. Snipre (talk) 15:59, 12 February 2014 (UTC)
I understand you want simple rules, but trading a problem for a prorlem is not really a good argument as we have to analyse the problem to compare them. For redundancy in my POV: a bot certainly can complete the relationships and track the inconsistencies. It seem also good for someone who has an author in his watchlist there is a new item in its neighboorhood. TomT0m (talk) 16:09, 12 February 2014 (UTC)

Quantities defaulting to +/- 1

I am wondering if this is already discussed before but, I think that the uncertainty in quantities default to 1. I believe this should default to no uncertainty. For example, when i edit population data. I need to edit twice just to remove the +/- 1. Do other editor feel the same way? Was this discussed before? --Napoleon.tan (talk) 01:16, 14 February 2014 (UTC)

Yeah, we pinged the dev team at WD:Contact the development team#Quantity precision. --Izno (talk) 01:34, 14 February 2014 (UTC)


Now that we have population (P1082) the problem is that wikipedia in almost all cases merge populated place and administrative division. for example Assisi (Q20103) is both an administative division comune of Italy (Q747074) and a ppl, but administrative division has got 27377 people, ppl place only 3732 people, the same problem is for altitude ecc., in the future we will have same problems with boundaries coordinates --Rippitippi (talk) 20:43, 1 February 2014 (UTC)

Hi Rippitippi : what is a ppl ? If there two concepts, there should probably be two items on WikiData (and probably two articles on the wikipedias but that's an other question). Cdlt, VIGNERON (talk) 21:37, 1 February 2014 (UTC)
ppl=populated place --Rippitippi (talk) 22:40, 1 February 2014 (UTC)
Yes, we need two items in those cases. So you have to separate the ppl and the adm div. Both, in many cases, have to be linked to the same article in some way.
I see, when I work with these items related to Sweden that many projects add a coat of arms to the ppl-artícles, even if they also have an adm div-article, and that is really strange. When the bots here insist on adding them, I put a novalue to P94 here, to prevent them to readd them again. -- Lavallen (talk) 07:57, 2 February 2014 (UTC)
Rippitippi : thanks, but what concept is a populated place ? (in France we nearly only have communes). where did you get the « 3732 people » population and other data ? (I see nothing on the italian article or elsewhere). Cdlt, VIGNERON (talk) 12:46, 2 February 2014 (UTC)
VIGNERON Take a look to Sabran (Q375584) the village sarban=ppl has for example 300 peoples but in the sarban commune there is village combe=ppl for example with 200 peoples so sarban + combe = 500 peoples so the peoples of sarban commune=administrative division is different to sarban village=ppl and all the wikipedia have this problem, assisi data come from Istat (Q214195) --Rippitippi (talk) 13:07, 2 February 2014 (UTC)
Often you find different wikipedias divide the pages in different ways. Some have separate articles for the administrative district and for the same name village which is the seat of government of that district. In other cases there is only one article dealing with both.
Remember though that an article which is mostly about the village can be considered to be an unfinished article about the whole district where it happens that most of the stuff added so far is about that one bit of the district so you can have an article which is mostly about the unincorporated village and a wikidata item where most of the facts are related to the administrative district. Filceolaire (talk) 13:36, 2 February 2014 (UTC)
Thanks Rippitippi for the explanation. Thanks too to Filceolaire.
In France, it's simplier : in 99 % of the cases we only have an article for the commune and the INSEE (Q156616) only gives data and stats for the communes (the only exception is for very populated cities like Paris or Marseilles but we already have separate articles and items for theses sub-communal territories). For the example, Sabran (Q375584), nobody has never had data for hamlets like Combe : no source → no data → no item  . Plus, because there is lot of little communes in France, the commune and the ppl have almost the same population/altitude/etc.
Cdlt, VIGNERON (talk) 14:06, 2 February 2014 (UTC)
Not is simple, is simply wrong ;-) because if INSEE (Q156616) not give data this does not mean that sarban and combe are two different ppl and we must rappresente two different item with different coordinates --Rippitippi (talk) 14:20, 2 February 2014 (UTC)
It's kind of true… But it's not just the INSEE, it's all the books in the world! You'll never find a source for the population of Combe. There a reason why articles on French Wikipédia are *allways* about communes and not ppl ;) In facts, the concept of « ppl » doesn't really exist in France, it's too fuzzy. The nearest concept in French is probably urban agglomeration (Q159313).
Sure we could find coordinates and altitude on a map for Combe but what else ? How could you even be sure that Combe is really populated ? Is it really worthy to create an item for Combe with just the coordinate and that will never be linked to any articles ?
Cdlt, VIGNERON (talk) 15:30, 2 February 2014 (UTC)
There is plenty of items with no article in Wikidata. And it's a feature, not a bug. If Combe is an identifiable entity and we can use it to make statements, there is no problem into having an item. It's just one click and a few keystrokes. TomT0m (talk) 16:11, 2 February 2014 (UTC)
Huh ? Are you sure ? What about the rules Wikidata:Notability ? No page on any projects (1), no « serious and publicly available references » (2), not sure about « structural need » (3, needed for what ?). Cdlt, VIGNERON (talk)
This is exactly what "structural need" is about. -- Lavallen (talk) 14:01, 4 February 2014 (UTC)
Ok but why/for what is it needed ?
What data will be is these items ? (for France, I may be mistaken but I can only see coordinates and « X is a part of Y »…).
Cdlt, VIGNERON (talk) 14:12, 4 February 2014 (UTC)
Some statements are more simply kept in separate items, to not mix them with each other. I have for example started to think about how the results in local elections should be stored. I guess that each election, for each year and each commune have to be stored in separate items. The alternative would result in confusion about how the statements are related to each others. A single local election in a commune with population of 200 is not notable for an article on WP, but to keep the integrity of the database, I guess we need to have them in separate items. -- Lavallen (talk) 14:31, 4 February 2014 (UTC)
Ok, I see. Thanks for the explanations.
But once again, I'm not really sure it's applicable for France. More than half of the French communes doesn't have divisions for the elections. For the others, the official data (and only easily available data) are already agregated for the whole commune. For Rennes (Q647), the data for the 150+ divisions are freely available, could you explain how you sees it ? By the way, 200 electors is quite a big commune in France ;)
Cdlt, VIGNERON (talk) 15:43, 4 February 2014 (UTC)
France have very small administrative divisions, > 30000 commune. I guess it often is hard to find smaller entities having an article in France. Compare that with Sweden, who have (more or less) the same (geographic) size as France, but has only 290 communes. Many projects (but not the Swedish) are mixing the articles about the locality who have the same name as the commune with the commune tiself. That is why items about Swedish localities often are added such properties like coat of arms image (P94) even if it not relevant for it. Swedish localities never have a coat of arms, it's only administrative entities who have such properties. -- Lavallen (talk) 19:30, 4 February 2014 (UTC)
There is a lot of potential statements that could use Combes as an item, for example some historic figures that use Combes as an item, Combes can be a former something, a part of some bigger entity ... TomT0m (talk) 19:59, 4 February 2014 (UTC)
Combe is a very bad example, there is nothing to say about it, now or ever… Here some other case I know : Veneffles (Q3555470) (former commune until 1971, no data since), Pont-Réan (Q3396336) (little town, no data). Could you find some data to add on these items ? Cdlt, VIGNERON (talk) 07:38, 6 February 2014 (UTC)

I think what we have to decide is:

  1. same items ppl+adimin division with different proprieties to maintain adherence with the majority of the wikipedia entries
  2. different items for ppl and admin division but there will be confusion with links to wikipedia someone will point to admin div someone to ppl --Rippitippi (talk) 14:31, 2 February 2014 (UTC)
A solution to this is to treat it as "Bonnie and Clyde", i.e. "X (ppl) and X (adm div)". -- Lavallen (talk) 07:32, 3 February 2014 (UTC)

We had similar discussion in and it looks the best way is create one more item for the part of municipality with the same name, there should be number of houses, inhabitants, coordinates, contains administrative territorial entity (P150) and located in the administrative territorial entity (P131), or commonscat, but usually no link to wikipedia. JAn Dudík (talk) 09:59, 3 February 2014 (UTC)

Fully support creating different items for different concepts. Same goes for islands. A province may have one large island and some smaller ones. Then the land area of the province is bigger than that of the large island. Also extreme points can differ. So there should be Greenland (country) and Greenland (island). Androoox (talk) 22:56, 4 February 2014 (UTC)

Exactly. Create an item if we can make statements about that item. Filceolaire (talk) 22:39, 7 February 2014 (UTC)

Can someone please define what a "populated place" is and how that differs from an administrative division? In the U.S., most cities have several different populations. For example, Nashville has a consolidated population, a balance population, a metro population, and combined statistical population. Sometimes these different ways of defining the city have separate articles, sometimes they don't. In the case of Nashville, for example, there is a general "Nashville" article that basically covers all 4 definitions, and two separate articles for the balance and metro definitions (but no separate articles for the consolidated or combined statistical definitions). Good luck figuring out how to translate than into Wikidata! Kaldari (talk) 22:20, 10 February 2014 (UTC)
Each nation have it's own way to define things. Your example explains very well how it's applied to U.S. The first example above was from Italy, and I see the same problem in Sweden. There can be many entities with the same name. In Sweden we have urban areas as examples of populated places. The largest urban area in a municipality often have the same name as the municipality (maybe not in Swedish, but in many other languages), but it almost always cover only a small part of the municipality. On svwp are we always spliting the article about the Swedish municipalities from the article about the urban areas. Other projects are mixing the subjects in one article, or tends to have two articles, but are still mixing them. A parish, a civil parish, a district and a village often have the same name, but they do not have the same borders and population and the villages do not even have any modern statistics, since the statistics organisations have not recogniced them for the last 100 years.
Welcome to Wikidata:Requests_for_comment/Administative_divisions_and_populated_places to hopefully solve this! -- Lavallen (talk) 08:58, 14 February 2014 (UTC)


How should we handle wrestlers? As the most of theme are playing a fictional role, there must be two separate items, even the Wikipedia has only one. Otherwise it's not possible to make specific statements, or at least you don't know if the statement is referring to the wrestler itself or the character he is playing. Example: The Undertaker / Mark William Calaway (Q44304).

  • I don't know if Mark William Calaway has a brother, but the character he is playing has a half-brother.
  • Undertaker was died and rebirth later, Mark William Calaway surely didn't
  • Mark William Calaway profession is sportsman, Undertaker is something like Grim Reaper or so
  • Mark William Calaway is a real person, the Undertaker is a fictional character

This are just some examples about the Undertaker. There are more about him and thousands more about other wrestler which portraits not their own person.

It's not the question we should have two items, this is very clear we should, as we have also a Bon Jovi for the Band and (Jon) Bon Jovi for the musician. The question is how to proceed as the most Wikipedia who links to the Wikidata item are referring to both. We could:

  1. Relabel the item to 'Mark William Calaway' and create a new item "The Undertaker"
  2. Keep "The Undertaker", create a new item 'Mark William Calaway' and remove all statements which are referring to Mark William Calaway

-- 11:30, 9 February 2014 (UTC)

I say the best solution would be the second one as there is probably a lot of statement that refer to the fictional character. The main topic of the articles are probably the undertaker, and article should be linked to the item which identifies their main topics. The properties to link the two items might be similar to character role (P453) or cast member (P161), but I don't know if there is an exact match or a generic property that can be used. TomT0m (talk) 17:09, 9 February 2014 (UTC)
As I understand it Mark William Calaway is wrestling under pseudonym (P742) "Undertaker". The Undertaker is not really a fictional figure since he does not exist in a fictional narrative. /ℇsquilo 11:45, 14 February 2014 (UTC)
Catch is not a sport, it's a show, with a scenario and all … TomT0m (talk) 18:08, 14 February 2014 (UTC)

Reasonator in the toolbox

I had always wanted to have a link in the toolbox to view the current item on Reasonator; maybe someone else shared the same desire, and will be interested in this little user script.--Underlying lk (talk) 13:28, 14 February 2014 (UTC)

Love it. Can we please make this an official gadget? --Tobias1984 (talk) 13:58, 14 February 2014 (UTC)
I have nothing against that of course, but perhaps it should be tested more extensively first? For now, I have added it to the user scripts page.--Underlying lk (talk) 02:50, 15 February 2014 (UTC)

follows (P155) & followed by (P156) & structure replaced by (P167)

Now we have two property means succeeded by: followed by (P156) & structure replaced by (P167). However, in my opinion, "replaced by" or "succeeded by" have 6 different definitions, each of that have different words in Chinese:

  1. "Next item" in 1 (Q199)=>2 (Q200); (both exist at the same time)
  2. "Next person of a position" in Barack Obama (Q76)=>George W. Bush (Q207); (both exist at the same time, but don't hold the position at the same time)
  3. "Building replaced this building or structure, at the same location" in Singer Building (Q651362)=>One Liberty Plaza (Q1144187); (don't exist at the same time)
  4. "Next edition" in The Plant List 1.0 (Q15628807)=>The Plant List 1.1 (Q15628808); (not different work but different edition of work)
  5. "Next episode" in Cougars (Q5176063)=>Secrets and Lies (Q7444489); (completely two different work (though in a sreies), not rewrite/republish/update)
  6. "Replaced by organization/regime" in Ming dynasty (Q9903)=>Qing dynasty (Q8733); (usually don't exist at the same time)

Although "succeeded by" means these six above in English, and in many European languages they share she same word/phrase, the difference of word in Chinese causes a potential edit war about label and description:

  1. Ericmetro changed labels to 下一部作品, which only means the 5th definition
  2. Tntchn changed labels to 下一個項目 (means the 1st)
  3. Xiaomingyan changed label to 续作 (means the 5th)
  4. Xiaomingyan changed label to 下一个 (means the 1st)
  5. Xiaomingyan changed label to 继任 (means the 2nd)
  6. TianyinLee changed label to 续作 (means the 5th)
  7. GZWDer changed label to 下一项 (means the 1st)

Capmo requested a new property "replaces" in Wikidata:Property_proposal/Place. Ivan A. Krestinin suggests using separate properties firpersons, organizations and etc. probably these six above doesn't have one (at least) same word in Russian. Jakec rejected it because of "succeeded by" means these six above in English. Should we merge followed by (P156) and structure replaced by (P167) or use six separate properties for six definitions?

Note I had nominated a lot of separate properties in Wikidata:Property_proposal/Organization, Wikidata:Property_proposal/Person, Wikidata:Property proposal/Creative work before Jakec's action.--GZWDer (talk) 05:39, 14 February 2014 (UTC)

I am tired of having a lot of beginning date when I just mean this ... Please don't separate properties with almost same meaning and which in context are clear (for example for a human it seam clear that begin and end date like are birth or death, whereas birth or death of a company are another thing ...) (This was just a first reaction and a cry of the heart, we should apply parcimony principle here. TomT0m (talk) 11:06, 14 February 2014 (UTC)
I think the problem is twofold: 1.: What is the difference between followed by (P156) & structure replaced by (P167)? This is not thoroughly defined. The definition of P167 (being restricted to buildings) does not fit to parts of its application, e.g., IEEE 1471 (Q1653441). More or less, both properties define a strict order (in mathematical sense). The restriction to specific use cases should IMHO be avoided. I would suggest to either merge them (I do currently not see why P156 should not work for all these use cases) or clearly define with property is to be used when (for example: P67 in terms of a replacement where the replaced item is, thus, no longer valid; this is true for building or official positions, but not for numbers and episodes). This has to be discussed.
2.: It is not beneficial to create one property for each phrase in each language. We had this case in for the property sex, where some languages do not use the same word whether the item is human or a non-human animal. Here it is clear: Biology says, it is the same concept. Thus, you could circumvent edit wars by setting the property label to "下一项 OR 续作 OR 下一個項目 OR ..." (I do not speak Chinese) or search for a valid hypernym (Q609507).  — Felix Reimann (talk) 12:17, 14 February 2014 (UTC)
I think replaced by in the exemple of building is meaningful : something was at the place, it was destroyed, then some other building was built at the same place. For the case of sequences of virtual things, this is different : an episode of a TV series does not destroys nor replaces the old one, it's the next in line in sequence of episodes, which is well defined. So my gut feeling is : use followed by if there is a natural and defined sequence of things, and replaced by if the replacement item if something concrete was destroyed and there is no natural following in the sense there is no natural sequence in which it is included. A governement is meant to be replaced at the next election, a building is not really something that is a part of a things that were in this emplacement sequence ... If there is not much sense to create an item like governments of the third french republic (this one being meaningful), then use replaced by. Otherwise if we can define a sequence like The doors albums chronoligically ordered, use followed by ... in sequence ... like my question in this project on how to define sequences suggests. TomT0m (talk) 12:33, 14 February 2014 (UTC)
Is this "edit-war" a consequense of that zh mainly is a written language, rather than a spoken language? -- Lavallen (talk) 18:07, 14 February 2014 (UTC)
@TomT0M: I am not a big fan of narrow scope properties, but I am not sure "preceded by" is always clear. It is probably because I am no astronomer, but I have no idea of what it means in 4 Vesta (Q3030). I had seen other examples but forgot to write them down :|. But splitting it in a sensible way is not obvious either. --Zolo (talk) 18:02, 15 February 2014 (UTC)
@Zolo: This is because these statements are totally raw ... they should be linked some way to the sequece they belongs to, and the sequence should be
< this sequence > instance of (P31)   < sequence type >
part of or a in sequence qualifier should do the trick. TomT0m (talk) 18:24, 15 February 2014 (UTC) Wow, the number of typing properties for asteroids is astonishing

Auguste Schneegans (Q8340245)


To add the link ("in other languages") on wp:de de:Carl August Schneegans ? Thank's and have a good day (not so cold !). Best regards Mike Coppolano (talk) 09:23, 14 February 2014 (UTC)

Done. You can do this yourself, see Help:Merge. It is now Auguste Schneegans (Q1036880).  — Felix Reimann (talk) 11:17, 14 February 2014 (UTC)
Thanks for the advice. Mike Coppolano (talk) 06:35, 16 February 2014 (UTC)

Wikidata and other wikis

What is the general opinion about connecting Wikidata also to Wikis outside of the Wikimedia foundation. For instance the several Wikis of Wikia. An example: The Sherlock Holmes Article in the Bakerstreet-Wiki can provide much more detailed information about the topic Sherlock Holmes (Q4653) then all the offical Wikimedia wikis. Not to mention all the articles about books, films and video games.

The Girl Who Waited (Q3069528) has an English text in the English Wikipedia but no German text at all. The english article is prominently linking to the english Tardis Wiki which also provides a German text.

It would be a waste not to use all this potential. --Shisma (talk) 16:02, 11 February 2014 (UTC)

Before doing any development work to connect wikidata with other wiki than those of the Wikimedia Foundation, please let the development team working on the tools necessary for a complete application of wikidata in wikipedias: we are waiting for the numeric datatype with units, the multilingual datatype, the possibility to load data of differents items in an unique wikipedia article, the queries ...
Right now the phase 2 of wikidata development in wikipedia is not fully implemented so we have to focus on some priorities. Snipre (talk) 16:10, 11 February 2014 (UTC)
@Shisma: Have a look at Wikidata:Development plan to see the work which is already planned. Snipre (talk) 16:14, 11 February 2014 (UTC)

I didn't file a bug report yet. I just asked for the general opinion about such a project ^^ --Shisma (talk) 16:15, 11 February 2014 (UTC)

Hey :) Linking via identifiers in properties is already possible and done a lot. More support would be nice but is not on the horizon at this point. Simply too much other stuff to do that is more important. --Lydia Pintscher (WMDE) (talk) 12:07, 16 February 2014 (UTC)

Wikidata items linked to redirected Commons category

Is there a list somewhere of all the Wikidata items linking to a Commons category with the category redirect template? I think those ought to be deleted as they fail Wikidata's notability criteria. TeleComNasSprVen (talk) 10:41, 14 February 2014 (UTC)

No list currently in existence that I can think of or find. Category redirects do fail WD:N and can be removed as identified, but it isn't too pressing of an issue. Ajraddatz (Talk) 07:18, 16 February 2014 (UTC)

Help expand Wikidata:Tools?

Hey :)

I get a lot of people asking me for tools built around Wikidata. I usually point people to Wikidata:Tools. However quite a few tools are missing there - for example some by Magnus. If you know of a tool that is missing please do add it. That page is the primary point of finding cool stuff people built with and on top of Wikidata. --Lydia Pintscher (WMDE) (talk) 14:29, 16 February 2014 (UTC)

Ready for data access for Wikisource?

Hey :)

Just a quick reminder that as announced we are planning to enable data access (aka phase 2) for Wikisource on 25th. Coordination is taking place at Wikidata:Wikisource. --Lydia Pintscher (WMDE) (talk) 15:04, 16 February 2014 (UTC)

Wikipedia watchlist

I have the option enabled on the English Wikipedia to show changes on the Wikidata items which are on my Wikipedia watchlist. Since a couple of days, edits in such items do not show up on my watchlist. Is this a problem of the English Wikipedia, of the Wikidata, or smth else? I am sure I did not change preferences, and I still have an option of switching Wikidata edits off (giving a hint tht they are on).--Ymblanter (talk) 22:09, 11 February 2014 (UTC)

Wikidata Items marked D in "recent changes" of de.Wikipedia
Same problem on german WP, see de:Wikipedia_Diskussion:WikiProjekt_Wikidata_in_Wikipedia#Einbindung_von_Koordinaten and Wikidata:Forum#Wikidata-Bearbeitung_in_Wikipedia. "Show wikidata" does work on "recent changes" though, lots of "D"s.
But, anyway, the wikidata edit comment shown on WP is quite useless, it's either "The wikidata object was changed" or "2 changes" (or 3, 4, etc.). You have to click on the diff to find out more on wikidata. And I really don't care if some wikidata label was changed in 1 of 250 languages - and since this feels like 99% of those "wikidata changes", i don't bother to click on those diffs. And since i don't intend to look at useless comments about random "wikidata changes" and to click on wikidata diffs, i have disabled the "show wikidata" function on my watchlist. And so has everybody else on WP, i guess. --Atlasowa (talk) 17:18, 12 February 2014 (UTC)
Which in turn explains why nobody even notices that "show wikidata" doesn't actually show wikdata changes. --Atlasowa (talk) 17:29, 12 February 2014 (UTC)

@Ymblanter:: Could you or someone else please file a bug? I also can't get changes to show up on enwp. We need to investigate. --Lydia Pintscher (WMDE) (talk) 12:16, 16 February 2014 (UTC)

I looked for a bugreport, didn't find it, but found a lot of bugs ;-)

--Atlasowa (talk) 22:18, 16 February 2014 (UTC)

script for blanking labels/descriptions?

sometimes I need to blank labels or decsriptions for many languages, especially when merging or splitting disambiguation items. It takes some time to do this manually. On the other side adding labels and descriptions is easy with script help. i think a few weeks ago I read about a user script which allows blanking, but i don't find it again. does someone know? Holger1959 (talk) 22:50, 13 February 2014 (UTC)

I don't know about a blanking script, but my Label Collector at least allows editing of all existing labels and descriptions at once. Workflow would be: Open item, open Label Collector, press "Extended/collapse all", manually blank all input fields, press "Save". --YMS (talk) 06:27, 14 February 2014 (UTC)
See User:Jitrixis/dataDrainer.js. --Stryn (talk) 17:07, 14 February 2014 (UTC)
thank you both! works great. Holger1959 (talk) 05:48, 17 February 2014 (UTC)


I have {{#babel:en}} on my user page, and speak no languages other than English, but am constantly being prompted to add labels in "Scots" & "Cymraeg". How can I stop this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:28, 15 February 2014 (UTC)

Move to somewhere people do not talk Scots or Cymraeg! :) It's probably suggested since your IP is related to an area where some people speak those languages. I have more or less the same problem with "Finnish" and "Sami", probably becase the area I live have native population of those languages, but I do not understand a word. Cymraeg is much easier to learn than Sami or Finnish. -- Lavallen (talk) 06:24, 16 February 2014 (UTC)
Maybe you should count your blessings. You are bothered by only two languages that you are not going to fill in. I have a screen full of languages that I am not going to fill in and often cannot do anything before scrolling it out of the way. - Brya (talk) 06:39, 16 February 2014 (UTC)
Can you please file a bug on for this? If you have babel information on your user page it should not show you other languages than that. It looks like we missed a corner-case there. --Lydia Pintscher (WMDE) (talk) 12:20, 16 February 2014 (UTC)
Thank you; done, at - Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:08, 16 February 2014 (UTC)

Sequencing of suggestions

If I add, for example, a property, P21 "sex or gender", to an item, and type "male" into the field for value, then the relevant entry, Q6581097, is the sixth one shown. This requires me to scroll down on my small netbook screen; and is irksome. It would be good if the system could use some sort of logic, and realise that the most commonly used value should be presented first. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:37, 15 February 2014 (UTC)

It's probably a consequence of that many items have a English label starting with something like "mal.....". Learn Cymraeg, it does not have so many labels yet! :) -- Lavallen (talk) 06:29, 16 February 2014 (UTC)
A team of students is working on this. I hope they'll have a first version we can deploy soon. --Lydia Pintscher (WMDE) (talk) 12:21, 16 February 2014 (UTC)
That's good to hear; thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:01, 16 February 2014 (UTC)

Querying latest software versions

Hi, in discussion here you state that latest software versions can be obtained from P348 property. Could you please help me how to do this? If I insert just P348 property, there are all versions listed in infoboxes (like in cs:QGIS). --Strepon (talk) 17:15, 13 February 2014 (UTC)

I moved this question to the project chat because I haven't figured out how to do that myself. --Tobias1984 (talk) 17:24, 13 February 2014 (UTC)
Do we have a page for how to solve these things with Lua? If not, that is something we really need. --Tobias1984 (talk) 10:57, 14 February 2014 (UTC)
I don't think we have one. A "Lua showcase" or "Wikidata integration showcase" page would be cool. Anyone up for starting one? --Lydia Pintscher (WMDE) (talk) 12:17, 16 February 2014 (UTC)
Allready done on Help:Phase 2 on Wikipedia.--Snaevar (talk) 14:22, 16 February 2014 (UTC)
I was actually thinking of something more along the lines of Wikidata:Tools. --Lydia Pintscher (WMDE) (talk) 14:26, 16 February 2014 (UTC)
Here is an start: Wikidata:Client modules.--Snaevar (talk) 01:04, 18 February 2014 (UTC)
As for making an lua script for this purpose, you would need to ask the script to check whether there is an item connected to the page, whether there are any statements, and so on. Within that, you would fetch the value of that property. In short, in order to get the first value from p348 you would use something like this:
local entity = mw.wikibase.getEntity()
if entity and and  ~= nil then
	if[0].mainsnak.datavalue ~= nil then

--Snaevar (talk) 14:22, 16 February 2014 (UTC)

Is there a tutorial page somewhere, that explains how to put such a code into Wikipedia? --Tobias1984 (talk) 15:45, 16 February 2014 (UTC)
Snaevar This code is too low level ... It should be put into a library and the example sjould look like :
import itemdataget 

local entity = mw.wikibase.getEntity()
return itemdataget.getclaims("p348")

on a tutorial

Yes, we should write such a library with functions like:
  • result, sources = getOneClaim() (first item according to rank/order; result formatted, i.e. page link in case of datatype item, date formatted according to precision,...; and the sources of the claim given as <ref></ref>... claims)
  • result, sources = getClaims() (same for set properties like "has parts", also in respect to the ranking)
  • result, sources = getAllClaims() (e.g., to generate lists, perhaps with a field separator or similar things)
All should have default but changeable settings for novalue/somevalue/no claim at all and similar claim conditions.  — Felix Reimann (talk) 16:51, 16 February 2014 (UTC)
I think test2wiki:Module:Wikidata will do what you are looking for, mostly. And oh, if you intend to use that script, then please copy it, do not attempt to import it (see bugzilla:45750).--Snaevar (talk) 22:50, 17 February 2014 (UTC)
Thanks to all for your help, the parameter rank=preferred is exactly what I need, unfortunately it is not yet supported (hope this will be added soon). --Strepon (talk) 08:21, 27 February 2014 (UTC)
I hacked the support for rank= at cswiki; is there any canonical repository of the Wikidata support module, or does every wiki maintain its own copy?? --Mormegil (talk) 16:53, 27 February 2014 (UTC)

{{Reasonator}} and {{Q}}

H(o)i, who is for the inclusion of something like that Paris (Q90)   in {{Q}} ? TomT0m (talk) 18:21, 16 February 2014 (UTC)

  Support for the template. The icon looks a little blurry on my screen. I tried to make a version that works better for small sizes. But maybe a professional can still improve it: --Tobias1984 (talk) 18:56, 16 February 2014 (UTC)
  Done for the svg icon replacement, thanks. TomT0m (talk)
@TomT0m: The template uses 12 px as definition for the icon size. That means on high resolution screens (including tablets and phones) the icon is almost not visible. Anybody know how to define graphic size relative to text size in Wikimarkup. --Tobias1984 (talk) 10:32, 17 February 2014 (UTC)
@Tobias1984: I tried a few stuffs this morning, but did not work yet, it might require a css class in common.css as the wikimarkup parser blocks a few things here (fortunately). TomT0m (talk) 11:19, 17 February 2014 (UTC)
I did some more testing on my phone. Actually all template icons have this behaviour. Also the larger I set the text, the smaller the icons get. I could imagine that this would be especially pronounced on 4K-screens (don't have such a device). Might be a Wikidata-wide or even Wikimedia wide problem, but one that will get more important as more and more devices have more pixels-per-cm. --Tobias1984 (talk) 11:48, 17 February 2014 (UTC)
I left a message on Mediawiki:Common.css. It seems weird that we can't use the em unit to be relative to the font size, maybe we should file a feature request on Mediawiki wiki. TomT0m (talk) 12:13, 17 February 2014 (UTC)
For 16 px this is my best try for it to render sharp on normal screens. --Tobias1984 (talk) 16:54, 17 February 2014 (UTC)
Please don't add this. 1. Rendering of a rather common template should be kept to a small load. 2. It's not attractive and changing the text size will not change the size of the image. If we're going to add a link to the Reasonater (I'm pretty sure we shouldn't), it should be in the form of a plainlink. --Izno (talk) 13:10, 18 February 2014 (UTC)
I also don't think that every Q-template-link should have the Resonator link by default (I somehow misread the proposal). But I think the {{Reasonator}} is useful in itself. --Tobias1984 (talk) 14:06, 18 February 2014 (UTC)
TomT0m created {{Q'}}, so in my opinion there's no longer the need to modify {{Q}}. — TintoMeches, 14:53, 18 February 2014 (UTC)
Tobias1984 I for myself (If I find a solution to the typographical templates) that it is a really interesting to make it very easy to access reasonator as it's way better for having a quick overview on an item, and it is a really frequent usecase. Probably more important. Izno I'll try to create a CSS code to not break the typo. TomT0m (talk) 16:48, 18 February 2014 (UTC)

Wiki loves European Parliament

From Monday 3 February to Thursday 6 February a group of about 50 Wikimedians were present in the European Parliament in Strasbourg to take photos of members of the European Parliament (MEPs). From about half of all members (766) of the parliament there have been photos taken during these days.

The category with photos can be found on Commons here and includes also the other photos that have been taken by the group members during the project in Strasbourg.

You can find which MEPs items need to be improved with this tool[39:27169]

Thanks for the help! --Pyb (talk) 12:32, 18 February 2014 (UTC)

Merge the same item

Items Q12766740 and Q3075593 are the same. Please merge them. Thank You. --Kusurija (talk) 16:05, 18 February 2014 (UTC)

  Done, thanks for reporting. In future you can do it by yourself, see Help:Merge. --Stryn (talk) 16:25, 18 February 2014 (UTC)

Sources for categories, templates, etc

Do we really need sources for Property:P31 of categories, templates, etc? Isn't links from wrong templates are just constrains violations? --EugeneZelenko (talk) 02:14, 16 February 2014 (UTC)

We don't. See Help:Sources#When_to_source_a_statement and item 1. of Help:Sources/Items_not_needing_sources. Filceolaire (talk) 22:05, 18 February 2014 (UTC)

Point in time for recurring events

Is there a decided property for recurring events like holiday. I was wondering if you can use point in time, does the date allow point in time with no year? How about holidays with multiple celebration dates on different country and cultures? --Napoleon.tan (talk) 08:29, 17 February 2014 (UTC)

There you go: day in year for periodic occurrence (P837). --Wylve (talk) 09:36, 17 February 2014 (UTC)
There is other periods of recurrence, we talked about a periodicity property in some task force (I think this was in the periodical one or in the book one, I don't remember exactly) TomT0m (talk) 09:45, 17 February 2014 (UTC)
We have items for each day of the year. I think we also have items for every day in the arabic (lunar) and persian (lunisolar) calendars, though not all of these had english labels last time I looked plus items for days like first Monday in September (Q14832552). Filceolaire (talk) 22:21, 18 February 2014 (UTC)
i don't really think that solves the problem of expressing the revolution period of Mars or the fact a quinquenal plan was supposed to come every five years :) Plus the calendar suggestion is OK in somo cases but the quantities datatype is I suupose going to express time lenghts … I'm not sure relying on cultural calendars is really cool for the physical time measure. TomT0m (talk) 22:47, 18 February 2014 (UTC)
@TomT0m: Each five year plan may need it's own item. I have no idea how to do the mars year - I will leave that to the astronomy experts. Filceolaire (talk) 17:26, 19 February 2014 (UTC)
@Napoleon.tan: I think cultural calendars are fine for recurring events like holidays - just not for duration or physical time measure. Where a holiday has multiple celebration dates on different countries and cultures then you can use
    • multiple values for P837 with qualifiers (it was on the first sunday till 1890; on the 2nd Sunday from 1891)
    • multiple items - en:WP may have one page discussing doggy day round the world but if, when you look at it, there are a number of different events, with different origins then you need each to have a different item so each can have it's own properties. Filceolaire (talk) 17:26, 19 February 2014 (UTC)

Changes on Help:Merge

I have just addded some text about next way to merge two pages. Could someone check the text before it is marked for translation? I'm not native english speaker. Matěj Suchánek (talk) 12:50, 19 February 2014 (UTC)

I am a native English speaker and checked this language and made one minor change.
That said I'm not sure it is appropriate to add this paragraph to the Help:Merge page as it deals with moving a single sitelink. I think a link to a general page about moving sitelinks would be better. Filceolaire (talk) 14:41, 19 February 2014 (UTC)
@Filceolaire: Why not? The page is about merging pages and I added text about merging pages. I wanted also inform user that they don't need to go to Wikidata to merge pages. Matěj Suchánek (talk) 15:30, 19 February 2014 (UTC)
@Matěj Suchánek: More that I think we need a help page on moves for complicated sorts, like the item I just posted below. This would discuss the 'move' tool in the sitelink edit menu as well. If we had such a Help:Move sitelinks page then a link to that would probably be better than adding this paragraph. Maybe. or maybe not. Since that page does not exist yet my point is moot. Either way the English is good and ready to translate. Filceolaire (talk) 17:01, 19 February 2014 (UTC)

archetype (Q131714)

archetype (Q131714) links to a page on WP:en which links to 4 different related concepts in philosophy, psychiatry etc. I have added links to these using has part (P527). archetype (Q131714) also has sitelinks to pages in 37 other languages and I have a suspicion that some of these pages relate to more than one of these 4 of these concepts (and should stay) and some relate to just one of these concepts (and should have their sitelink moved to the appropriate item). My knowledge of languages and philosophy aren't good enough to sort this myself. Could someone else have a look? Filceolaire (talk) 14:52, 19 February 2014 (UTC)

Universal Language Selector will be enabled by default again on this wiki by 21 February 2014

On January 21 2014 the MediaWiki extension Universal Language Selector (ULS) was disabled on this wiki. A new preference was added for logged-in users to turn on ULS. This was done to prevent slow loading of pages due to ULS webfonts, a behaviour that had been observed by the Wikimedia Technical Operations team on some wikis.

We are now ready to enable ULS again. The temporary preference to enable ULS will be removed. A new checkbox has been added to the Language Panel to enable/disable font delivery. This will be unchecked by default for this wiki, but can be selected at any time by the users to enable webfonts. This is an interim solution while we improve the feature of webfonts delivery.

You can read the announcement and the development plan for more information. Apologies for writing this message only in English. Thank you. Runa

As far as I am aware this shouldn't affect wikidata :) ·addshore· talk to me! 20:28, 19 February 2014 (UTC)

Tatjana Gsovsky

I would like to add English Tatjana Gsovsky, but the page looks strange, --Gerda Arendt (talk) 20:12, 19 February 2014 (UTC)

  Done --Tobias1984 (talk) 20:16, 19 February 2014 (UTC)


Perhaps as the illegitimate and unborn child of the Wikimedia Foundation projects, figuratively speaking, the unspoken-about and not-often-discussed project of Wikispecies seems left out of the grand interwiki-link integration schemes and machinations of Wikidata. Yet most of the content in that database is central to the interlink matters regarding Linnaean classification and taxonomy of the various species of life, in Wikipedia and elsewhere, despite initial concerns that Wikispecies might turn out to be a fork of Wikipedia. Should some sort of integration with Wikipedia be possible, and should Wikidata be the one to take up the task? TeleComNasSprVen (talk) 10:33, 30 January 2014 (UTC)

See Wikidata:Development plan. --Rschen7754 10:48, 30 January 2014 (UTC)
As I do not see Wikispecies on that list, I suppose then that the answer would have to be "no". TeleComNasSprVen (talk) 16:53, 30 January 2014 (UTC)
It's shortened to "Species" there, but it's on the "to be done" list - ranked last. --YMS (talk) 17:07, 30 January 2014 (UTC)
Most of the Wikimedia empire has a NOR and NPoV-policy, but Wikispecies does not and takes up an excentric position of its own. Thus it cannot be central. That is not to say that much of its content could not be useful here (especially links to original literature and author citations), but still a lot of it would be useless here. - Brya (talk) 17:25, 30 January 2014 (UTC)
I think it would be best to merge WikiSpecies back into Wikipedia. Wikipedia has so many pages on life forms that the reasoning for a separate project seem little pragmatic. A lot of work is also duplicated on the two projects (triplicated if you count Wikidata, n-plicated if you count every language that is coming up with their own infobox). For pure data pages Reasonator seems more fitting than the Wikispecies pages with only an infobox. --Tobias1984 (talk) 17:26, 30 January 2014 (UTC)
Wikispecies cannot really be merged into anything, as it adopts a single-point-of-view. But there is indeed a lot of duplication, and it is quite possible to argue that the real data should be copied into Wikidata and the project abolished. Not that this is likely to happen ... - Brya (talk) 06:31, 31 January 2014 (UTC)
Wikispecies looks like a perfect data collection to be integrated into WD, just take a look at the huge list of references. There should be a task force debating what are the needs for Wikispecies. (One main topic probably will be the quality of data.) With Reasonator it should be possible to display the pages in the same style as they are shown now on Species. --Kolja21 (talk) 06:48, 31 January 2014 (UTC)
I'm actually confused why Wikispecies has been left for "last" when it's such a trivial case to integrate, regardless of the quality of the data at Wikispecies. --Izno (talk) 20:26, 31 January 2014 (UTC)
@Lydia Pintscher (WMDE): - I also think we should do Wikispecies next. --Tobias1984 (talk) 20:35, 31 January 2014 (UTC)
It's technically simple but not politically. --Lydia Pintscher (WMDE) (talk) 22:55, 31 January 2014 (UTC)
@Lydia Pintscher (WMDE): That's obnoxious. How long would the actual deployment take (I'm guessing no more than 2 weeks?), and how can we help with pushing for the integration? I suspect that if the community said they wanted it, we might help with getting it integrated. --Izno (talk) 21:02, 6 February 2014 (UTC)

Related links for people reading this discussion in the future (or now): Wikidata:Project_chat/Archive/2013/04#Wikispecies, Wikidata:Project_chat/Archive/2013/02#Include_Wikispecies_into_Wikidata, mailarchive:wikispecies-l/2013-January/thread.html, mailarchive:wikispecies-l/2013-June/thread.html, mailarchive:wikimedia-l/2013-June/126306.html, etc. πr2 (tc) 00:26, 1 February 2014 (UTC)

Well, Wikispecies tried to prevent forking through its FAQ link on Meta, but I guess with Wikidata it might have failed in that regard. We'll just have to wait and see how these two projects cooperate with each other if at all. TeleComNasSprVen (talk) 07:34, 5 February 2014 (UTC)
@TeleComNasSprVen: What do you mean by preventing forking? --Izno (talk) 21:00, 6 February 2014 (UTC)
See Meta-Wiki:Wikispecies/FAQ where they aim to answer many questions and prevent becoming a fork, like at the "Is Wikispecies a fork of Wikipedia?" section and the "What happens if people start writing encyclopedia articles on Wikispecies?" section. TeleComNasSprVen (talk) 21:31, 6 February 2014 (UTC)
Please do not spend time integrating Wikispecies with Wikidata. Wikispecies should be killed with fire. The data there is hopelessly unreliable and completely out of sync with most taxonomic work that has been done in the last twenty years. Kaldari (talk) 21:53, 10 February 2014 (UTC)
I believe that Wikispecies site shall be completely rebuilded. It shall be nothing more than example, limited and nice interface to Wikidata, nothing more. It shall take all species data from Wikidata, represent them, show interlinks, links to Wikipedia articles (on user language, of course) and allow user to edit data on Wikidata thought Wikispicies interface. No additional data stored, no discussions (except whole-project ones), no local images. -- Vlsergey (talk) 03:55, 11 February 2014 (UTC)
As pointed out above Wikispecies cannot be integrated into Wikipedia. According to this statement, Wikispecies is set up to completely ignore the NPoV- and NOR-policies that are the cornerstone of Wikipedia. The ambition of Wikispecies is to be a new, independent, reliable scientific reference, built by professional scientists, so that Wikipedia can refer to it. Obviously this ambition was not realized, with a community where many do the typical Wikipedia-thing (copy-and-pasting-of-stuff-found-on-the-www). As far as I can tell, it is not possible to put a single quality stamp on its contents (there is good stuff and bad stuff), but certainly it is not worse across the board than Wikipedia (lots of real junk in Wikipedia, also).
        Integrating Wikispecies into Wikidata should be possible (it would help to lose the original taxonomic judgements, so alien to Wikipedia), but politically this is unlikely to happen (it is very hard to close any part of the WMF empire). Just like it looks to be hard to lose the terrible "other languages"-obstacle here on Wikidata. - Brya (talk) 11:56, 11 February 2014 (UTC)
Re User:Vlsergey, local image upload has been turned off 9 years ago. As for the Wikispecies community, we do not want this integration without careful considerations for introducing errors. Is it so hard that when we spoonfeed you with links on why such integration shouldn't proceed at this time, you guys turn a blind eye on the technical issue and focus on the "holistic" portion? Since many don't even bother to dig a little bit of information, allow me to repeat the same statement from last year on technical issues that needs to be resolved. OhanaUnitedTalk page 19:30, 11 February 2014 (UTC)
Re User:OhanaUnited. The question in subject is not about "shall we turn it off (on) right now or not". The question is direction where Wikispicies is going. If wikispicies community agree with deep integration, and, de facto, serving as nice and user-friendly frontend for Wikidata, technical problems will be solved. And the 4-th point is merely a "interwiki conflict", and i see no reason not to solve them in usual way. -- Vlsergey (talk) 09:21, 12 February 2014 (UTC)
If you wish to discuss where Wikispecies should be heading, then do it at Wikispecies. People who are most concerned about the project is in Wikispecies, not here. OhanaUnitedTalk page 06:41, 14 February 2014 (UTC)
Re Brya. I see no problem in the Wikispecies statement regarding NPoV and NOR. The statements says "we don't want any disputes, we just present taxonimical information". The same, actually, applies to Wikidata in broad sence: Wikidata doesn't provide place for discussions or NPoV (i mean, there is no way to explain the weights of different points in Wikidata). Both projects are quite similar in this way. -- Vlsergey (talk) 09:27, 12 February 2014 (UTC)
I think the problem of being bound to a normal wiki forced the Wikispecies community to present "one" state to the taxonomic hierarchy with all pros and cons this approach results in. Wikidata is however able to store "all" (important) views on taxonomy (also historic ones) which is, I think, an advantage. Also, it is possible to add sources very specifically to the claims which are indeed backed up in the respective source. I would welcome the Wikispecies community to have a look at how we started to model things here, see Wikidata:Taxonomy task force.  — Felix Reimann (talk) 11:10, 12 February 2014 (UTC)
@Vlsergey: the NPoV-policy can be summarized as "When a matter is in dispute, present all points of view fairly and proportionally". Your "we don't want any disputes, we just present our own point of view" is as bad a violation of the NPoV-policy as it can get. The same goes for the "It exists as a database aggregating the classifications and genetic family tree of all species of life"; in the real world there is no "family tree of all species of life", this is something created ("aggregated") especially for Wikispecies, a new synthesis, directly in violation of the NOR-policy. As Wikispecies is a separate project this is OK, but Wikispecies is not compatible with Wikipedia.
        You might say that Wikispecies is a particular subset of taxonomic information. Much in Wikispecies may be encompassed in Wikidata, but Wikispecies is much more limited than Wikidata is intended to be. If things work out there may easily come to be an order of magnitude more data on taxa in Wikidata than ever could be in Wikispecies. - Brya (talk) 17:31, 12 February 2014 (UTC)

Wikispecies and Reasonator

Maybe Reasonator is the model for wikispecies. By that I mean that Wikispecies becomes a specialist front end to the wikidata info, like reasonator is for wikidata info but customised fro species. All the data and references are kept on wikidata but they can be accessed through the specialist front end.

If there is a problem with references which are not from refereed papers then that is a matter of using wikidata to tag the reference with a suitable warning. IMHO Filceolaire (talk) 17:30, 18 February 2014 (UTC)

That's a good idea, though I still question the need for Wikispecies as a separate entity in that case. Virtually all of the editing would happen here, and Wikispecies would just be the front-end of part of Wikidata. It would be much nicer to just merge it in here, though I doubt the Wikispecies community would agree to that. If they'd agree to a compromise as suggested in your proposal, then it would be acceptable. Ajraddatz (Talk) 17:52, 18 February 2014 (UTC)
It actually doesn't really matter if we integrate Wikispecies into Wikidata. Wikidata develops much faster: Wikispecies has below 200 active users (compared to 13000). It is just a matter of months until we have comparable data. Just as Wikipedia adding current events made WikiNews obsolete, Wikidata (and Wikipedia already having 10^5 taxon articles) will make WikiSpecies obsolete. --Tobias1984 (talk) 18:18, 18 February 2014 (UTC)
Mere numbers do not really mean anything. I have no doubt that Wikidata will be bigger than Wikispecies, just integrating the CoL-data (>10^6 items) will make sure of that. And it is quite conceivable that bots will start importing real taxonomic and nomenclatural data (instead of low-grade CoL- and ITIS stuff), bringing up standards at Wikidata at the same level (or beyond), on average, as that at Wikispecies. But if you look at who is sorting out the CoL-data (really quite simple compared to other things), this is done by just a handful of users. Both Wikispecies and Wikidata have only few users who know what they are doing. - Brya (talk) 06:41, 19 February 2014 (UTC)
Please be careful about the Catalogue of Life data. The CoL project has been stalled since Frank Bisby (its founder and driving force) died in 2011. The project was pretty much abandoned by the University of Reading after that and just recently moved over to a new host, Naturalis. Maybe it will be revitalized under Naturalis, but who knows. Regardless, a lot of the data sources that CoL uses have themselves either died or gone stale since 2011 (and some of them weren't considered authoritative to begin with). I'll agree that the CoL data is an order of magnitude more comprehensive and up-to-date than Wikispecies (which often relies on publicly accessible pre-1923 taxonomies), but we should be very cautious about mass-importing any large taxonomic databases. The best approach is to import smaller specialized databases as these are much more likely to be well maintained. Also I should mention that from my experiences with Wikispecies they do not seem to have any interest in modern cladistic taxonomy, but instead strongly prefer Linnaean taxonomy even in cases where it is obsolete and deprecated. This may be one of the reasons why professional biologists have little interest in using Wikispecies. Kaldari (talk) 22:25, 20 February 2014 (UTC)
It is not a question of whether to import the CoL data or not. A few Wikipedias have already mass-imported it (as here). So the stuff is here, and all we can do is to eliminate the worst typo's and put the internal links in order.
        And yes, many users at Wikispecies are irrational when it comes to any rank higher than species. I don't really see why any rank higher than, say, family is included there. - Brya (talk) 05:59, 21 February 2014 (UTC)

Non-WMF wikis

Please comment on this just launched RFC. --Ricordisamoa 13:35, 21 February 2014 (UTC)

At the moment the only thing stopping this is technical implementation/development not really whether Wikidata wants it. Speaking with Lydia in the past; it is coming though is at least more than at least 1 1/2 years away. Though I'll ask Lydia to give a more realistic update here. John F. Lewis (talk) 13:40, 21 February 2014 (UTC)
Yeah I will not have the team spend time on this at this point. We have identifiers that do the job for now. There are a lot of other things to work on first. --Lydia Pintscher (WMDE) (talk) 14:21, 21 February 2014 (UTC)
But also, it is an Open Source project, and external developers are more than welcome to work on this right now if they want. --Denny (talk) 17:09, 21 February 2014 (UTC)

please comment

Hello all, there are more than 250K empty items (actually there are more than 750K items without sitelinks but 500K of them belongs to Chinese features and meet critics of WD:N) I'm pretty sure we need to delete at least 200K items, I requested to run a code to find suitable ones for deletion and requested for approval 4 months ago but It's still open. If I run the code, It'll delete a very high proportion of the items so Please comment here and if you think you can give the permission, give it and let it begin Amir (talk) 02:45, 19 February 2014 (UTC)

@Ladsgroup: User:Hoo man will probably do this.--GZWDer (talk) 05:31, 19 February 2014 (UTC)
@GZWDer:. You maybe havn't noticed: "Amir" and "Ladsgroup" is the same user. -- Lavallen (talk) 14:02, 19 February 2014 (UTC)
The absence of sitelinks is not all-important, it is also necessary to check for internal Wikidata-links. - Brya (talk) 06:45, 19 February 2014 (UTC)

I'm able to find items which meet the criteria, yes (no langlinks, no statements and not linked by any other item). Problem with that is WD:N #2 which basically means that almost everything is notable (and needs to be checked by hand). Because of WD:N #2 and the past complaints, I probably wont do any further mass deletions like that (at least without some more discussion). Despite of that, I will do some very conservative deletions today or in the next days (a few thousand items will be affected, I guess). - Hoo man (talk) 15:02, 21 February 2014 (UTC)

We should also check if the item is not used anywhere, i.e. if WhatLinksHere is empty (from NS0). Or, as Hoo said in IRC, "Entity not used anywhere (not linked from any page) AND entity has no sitelinks AND entity has no statements AND edits less than 3 or 4 (to not catch vandalized items or so)". This sounds safe. We should go ahead and delete those. It is trivial to save those that should be saved, e.g. make a statement about them or use them in any statement anywhere. But if that is not the case, why not delete it? --Denny (talk) 17:07, 21 February 2014 (UTC)
@Denny: I've just deleted 6622 items which met the criteria outlined above (I used further filter criteria to make double sure that I don't delete any items which still have value) - Hoo man (talk) 04:15, 23 February 2014 (UTC)

@Hoo man: please note that my bot only deletes items that had one sitelink and the sitelink got deleted in the wiki (It's a common thing) or the sitelink removed and added elsewhere (means it's an incomplete merge and needs to be done by this bot) it doesn't work that way you think. @Denny: all of things you said can be done in the code very easily but as I just said the way my bot works I think it's not necessary Amir (talk) 18:22, 21 February 2014 (UTC)

That's how in the past one perfectly admissible item I created got deleted because I thought it would secure it to create an item on Wikipedia. Unfortunately the article got deleted, then the item, so don't forget to check the item is not used in any statement before doing that. TomT0m (talk) 18:48, 21 February 2014 (UTC)
@Ladsgroup: I was describing how I searched for items which are up for deletion, not trying to explain your bot. - Hoo man (talk) 00:18, 22 February 2014 (UTC)
@Hoo man: okay, sorry for the misunderstanding. @TomT0m: if the an item is used in a statement before, it will have backlink(s) and can't be deleted because of the algorithm. that's why Cygnus X-1 (Q332674) is listed in backlinks of Cygnus constellation (Cygnus (Q8921)) because it's used in constellation (P59) of the itemAmir (talk) 06:26, 22 February 2014 (UTC)

Amendment to the Terms of Use

Small survey in WP:fr

I just want to give the result of a small survey in WP:fr about the implementation of Wikidata phase 2. The question was "Do you agree to implement phase 2 of Wikidata for infobox ?". The results are:

  • 23% yes
  • 43% yes but...
  • 34% no

The main open question for the people who said yes but... are

  • the difficulty to use the lua module to extract data from wikidata
  • the need of quality check for the data present in wikidata
  • the need to track modifications in wikidata for statements used in infoboxes from wikipedia

The main conclusion is an implementation project by project with a preliminary discussion about how the data from wikidatat will be used. Snipre (talk) 17:19, 22 February 2014 (UTC)

About point 1: We can't expect the typical Wikipedia-user to learn programming. Even templates discourage many people from contributing. If Wikidata can't work out of the visual editor, and the infoboxes can't be assembled like a lego castle we can't expect people to use it. --Tobias1984 (talk) 19:35, 22 February 2014 (UTC)
Agree, but it would be good if the skilled programmers here could fix some lego bricks? (The graphic design of the templates often look different in different projects, so I do not think we should bother much about that.) One problem is that we do not always have fully agreed of how a property should be used. I, for example, started to use P625 just before User:Zolo started a discussion of a change of it's use. That can be very frustrating... -- Lavallen (talk) 19:42, 22 February 2014 (UTC)
As a regular here I think this is a realistic response. We have, in my opinion, made a lot of progress over the last two years but there is still a lot to do. I think we will make a lot more progress over the next year.
Does anyone else think we should enable wikibaseclient on wikidata so we can try out infoboxes on item talk pages? Filceolaire (talk) 23:17, 22 February 2014 (UTC)

How to access a property

Hello. Is there a way to access a property of an item thru a wiki page? Maybe something like this {{Q72#P6}} and this will be replaced by "Corine Mauch"? --Micha (talk) 09:25, 23 February 2014 (UTC)

User:Magnus Manske/missing props.js/help

Hi! Please help to improve User:Magnus Manske/missing props.js/help by adding translations of the page text in more languages, by adding translations of the property titles, etc. Please propose additions of properties, new Q/P combinations etc. Thanks in advance! לערי ריינהארט (talk) 09:52, 23 February 2014 (UTC)

Q131736 does not load

Q131736 does not show the page, but instead brings the browser to 100% load. I tried a range of different browsers, with and without my login. wget is the only thing that works. I find the download with wget to be somewhat large with 881915 bytes. — Finn Årup Nielsen (fnielsen) (talk) 01:08, 18 February 2014 (UTC)

I do not see anything problematic with "wget". — Finn Årup Nielsen (fnielsen) (talk) 01:23, 18 February 2014 (UTC)
It does load after a long time. The issue is that there are _a lot_ of statements all with sources in it. This makes rendering currently super slow. We're working on improving the situation. Possible solutions:
  • Wait until we have improved the performance for such items.
  • Remove statements or at least their sources.
I'd prefer the first one. --Lydia Pintscher (WMDE) (talk) 09:12, 18 February 2014 (UTC)
Actually since basically all of those sources are "imported from english Wikipedia" I recommend deleting those sources. That should speed it up a lot in this case. --Lydia Pintscher (WMDE) (talk) 09:16, 18 February 2014 (UTC)
Lydia, please don't advocate removal of sources. Regardless of the reliability of the source, it is of the utmost importance that we can tell external users where we got our information. --Izno (talk) 13:07, 18 February 2014 (UTC)
Do you really think that in this particular case the source is useful? Let's replace them with something that is actually a source instead. --Lydia Pintscher (WMDE) (talk) 15:09, 18 February 2014 (UTC)
It doesn't matter whether the source is useful in this case. It matters whether the source is actually the source, per the "say where you got it" principle. Until such time as there is a (are) reliable source(s) for a statement, removal of any source of "imported from Wikipedia" is quite frankly unwarranted. --Izno (talk) 15:27, 18 February 2014 (UTC)
Again, in my opinion Wikipedia is no source and will never be. For error correction, however, it is useful to know where the claim comes from. But what, if a user manually checked to validity of the claim? Given, the user is right and the claim correct. Then, also the use case "error correction" is gone and it would be feasible to remove the source: "imported from WP" is no valid source. Without the use for error correction, it is no longer better than no source at all.  — Felix Reimann (talk) 15:57, 18 February 2014 (UTC)
It is possible to overdo anything. Wikipedia as such is no source (lots of real junk in Wikipedia), so there is no point to referring to it, really. As a rule, it does not hurt to eliminate any "imported from Wikipedia" link. There is a real danger of loading down Wikidata with meaningless links to the point where Wikidata itself becomes meaningless. - Brya (talk) 18:20, 18 February 2014 (UTC)
@FelixReimann, Brya: Quite frankly, if I notice any one removing an "imported from xx Wikipedia" source claim without another source claim (which is not "I am the source", which is worse than saying it came from Wikipedia), I will revert the edit as if it were vandalism. That might get me hauled to WD:AN right-quick (heck, even stating it might get me hauled there, so don't test me, please), but I feel very strongly that we must always state where a claim come from until such time as a reliable source makes the same claim as our database is making. This is a basic fundamental of citing sources. Unsourced claims will be, and probably are, looked upon even more skeptically than Wikipedia-sourced claims. --Izno (talk) 21:26, 18 February 2014 (UTC)
I noticed this discussion earlier but decided not to respond til now. May I say, while I agree with Izno in that we must cite where information is coming from, I also agree with Lydia in that removing anything to get the load down is vital. There is a major major difference between a 10 minute load to get an item going 'imported from the English Wikipedia' and a 10 minute load to get an item going 'Stated in book xxxx'. For a first; importing from a Wikipedia in my opinion is poor sourcing to begin. We have a performance issue here, so I suggest we follow what a developer says as we would in all other cases. Do we want useless sourced information or easily accessible information? It is a tough call but the focus of the Wikimedia movement is 'Imagine a world in which every single human being can freely share in the sum of all knowledge' not 'Imagine a world in which every single human being can freely share in the sum of all knowledge if you wait 10 minutes to access an item'. I suggest we all use common sense here. Poor source or user accessibility. The latter is clearly more important here. John F. Lewis (talk) 21:35, 18 February 2014 (UTC)
Just one thing about the statements. The problem with the ICD identifiers is that they were given as ranges on Wikipedia. On Wikidata it makes more sense to just assign the individual codes to the items farther down the subclass-of-tree (The range then being the sum of all the subclas-of items). That would also get rid of some constraint violations. I can only open the item on the Reasonator Q131736    , which is why I can't fix it. --Tobias1984 (talk) 21:54, 18 February 2014 (UTC)
And in order to get MediaWiki:Gadget-AuthorityControl.js to generate a link, the item could simply store a "I" which redirects to the first chapter of ICD-10 which is "Certain infectious and parasitic diseases (A00-B99)" --Tobias1984 (talk) 21:59, 18 February 2014 (UTC)
@User:Izno: this is not a matter of citing sources but of gathering metadata ("A has copied it from B, B has copied it from C, C has copied it from D, etc"). It is quite common to have a statement in an important source (a classic book) repeated in thousands of other places, and the cloud of metadata (tracking exactly how it came to be in all those places) for just the one statement can reach quite staggering proportions. There are those who attach great value to metadata, but for purposes of actual information, or for the end user, it is valueless. It is not hard to imagine Wikidata being brought down by an enormous load of metadata, none of which advances the goals of Wikidata even one tiny bit.
        As to vandalism, I would not go so far as to judge including an "imported from Wikipedia" as vandalism, but it is not all that far from it, especially when it is done in cases where no source is necessary (as it is so by definition). - Brya (talk) 06:15, 19 February 2014 (UTC)
@Brya: I'm afraid I would disagree with you there. Our hope is that Wikidata will become the gold standard for machine readable data; a curated mass of consistent information that has been checked by hand, or at least better checked than any other data out there. Filling it up with a copy of every other database out there and hoping for the best is therefore not an option.
When we started populating the wikidata from infoboxes there was therefore an issue about how to manage the process of getting to our goal. Should we ban all import bots until they figure out how to import sources with the data? Should bots ignore data without sources? The compromise we agreed was that where a bot imports data from a wikipedia then that bot should say which wikipedia it got the data from. The bot doesn't have to give the specific page or the date imported. That let us quickly seed wikidata with data and get the project moving, while still flagging that the data has not been checked by a human and needs a proper source. It also highlighted places where there is a discrepancy between different language editions.
I hope that in a few years time we will have replaced the 'stated in wikipedia' references with proper references in the most used million items (about 5% of the items?) and that the rest will follow. Filceolaire (talk) 17:46, 19 February 2014 (UTC)
I'm also worried that the behavior of our bots are copied by newbies. References like "Imported from any magasine" are stated everywhere. If we haven't limited the use of this property in constraints, it's time to do so! And I also think it's time to make it mandatory for the bots to tell from which specific page on Wikipedia they take the information. A perm-url would always be required together with "imported from"! -- Lavallen (talk) 19:34, 19 February 2014 (UTC)
I mostly agree with that, except that the "imported from Wikipedia" is the default, and is to be assumed whenever no source is given. There is not really much point (sometimes no point whatsoever) to add it explicitly.
        it does look safe to assume that what in future will happen is not that the "imported from Wikipedia" will be replaced by "[...] proper references in the most used million items (about 5% of the items?) [...]". If proper references are going to be used, these will often yield other content than what is in Wikipedia ... (at least I assume that the intent is to give "proper" information, and not to find references to accompany what happens to be in Wikipedia). - Brya (talk) 18:49, 19 February 2014 (UTC)
I sometimes add statements without sources, but mainly when it can be implicitly derived from other statements. In the P131-statements in Rönninge (Q5391401), has only one source (yet), but the other can be derived from the first. (If something was located in Salem landskommun 1960, then it was located in Salem kommun from 1971-73, Botkyrka kommun 74-82 and new Salem kommun 83-.) -- Lavallen (talk) 08:34, 24 February 2014 (UTC)

Band member

I thought we had a property for band members but I can't find it now. What should we use for this? Filceolaire (talk) 10:24, 23 February 2014 (UTC)

AFAIK has part (P527). --Kolja21 (talk) 10:44, 23 February 2014 (UTC)
Hence the inverse is part of (P361), or is it member of (P463)? The definition of the properties as I understand them would fit for both. Ahoerstemeier (talk) 21:19, 23 February 2014 (UTC)

Terrible to no usability on some pages with Javascript enabled

Hi. It has probably been discussed already, but I find some pages very difficult to view as the Javascript code quickly becomes very slow to execute with more properties present. Pages about moderate-size cities are already slow to load here (one minute or two). A computer system capable of displaying HQ video should ideally be able to display those pages without much difficulties, or is it a Wikimedia requirement for everyone to have the latest hardware and software to be able to browse pages? Some pages are even impossible to load for me (unless I buy a muscle computer I guess), for example Zürich (Q72) where there are a lot of items about historical population count with sources and dates I don't see the point in coding that population history there as it's a big no-no for usability and is a very inefficient encoding method.

Browsing pages with Javascript disabled is real fast, the problem is that you can't edit/add properties that way (editing/adding sitelinks work however), even if some edit/add links exist they don't work... Don't developers ever test their stuff with Javascript disabled? -- Bjung (talk) 00:10, 24 February 2014 (UTC)

Yup, this is a high criticality bug already. --Izno (talk) 01:07, 24 February 2014 (UTC)
I hope it gets fixed at some point. I haven't been able to add any statement in the last 2 months because of this.--Micru (talk) 08:41, 24 February 2014 (UTC)
Izno, do you have a link to the corresponding bug report? Please w:WP:NOTIFY me in your reply. Thanks! Zazpot (talk) 15:13, 27 June 2017 (UTC)
@Zazpot: Please don't edit archived pages. If you would like to verify the status of some bit of information, please create a new thread on the project chat-proper. --Izno (talk) 16:36, 27 June 2017 (UTC)
Izno, thanks for your reply. I'm afraid I don't understand your request not to edit archived pages. (How else can threading be maintained?) Where can I find policies or guidelines backing up your request and explaining the rationale for it? In any case, I would be grateful if you could provide a link to the bug report mentioned above, either here, or on my talk page if you prefer. Thanks, and please w:WP:NOTIFY me in your reply. Zazpot (talk) 17:29, 27 June 2017 (UTC)
@Zazpot: Threads are maintained by linking to the previous thread.... As for the bug report, I'm sure someone else will be willing to help you if you post on WD:PC. I'm mostly inactive on this project. --Izno (talk) 18:32, 27 June 2017 (UTC)
Izno, OK, not to worry. Thanks. Zazpot (talk) 18:35, 27 June 2017 (UTC)

Can a list be a class?

On Wikidata:Requests for comment/Define lists on both "Wikimedia lists" and "Wikimedia categories"#Lists are classes I have a serious disagreement with @GerardM: about whether a wikipedia list can be a wikidata:Class. Can anyone else with an opinion chime in? Filceolaire (talk) 19:17, 24 February 2014 (UTC)

river coordinate data from en.wp

I don't know if this is useful to anyone or how to find/notify them if so, but (as a data lover myself) I recently modified the {Infobox river} template on en.wp to allow the source and mouth coordinates to be explicitly entered there. So that's another set of fields the wikidata import scripts will conceivably want to look at.

(That infobox is used by approximately 12,500 river articles on en.wp, although at this moment of course only a tiny fraction of the invocations are using the new parameters. There are also 13,600 en.wp river articles using the alternate {Geobox} template, which already allows coordinate specification.) —Scs (talk) 22:52, 24 February 2014 (UTC)

Wikidata:Guide to Adminship

Since commons:Guide to Adminship is linked from {{AdminWelcome}}, I copied commons:Guide to Adminship over to Wikidata:Guide to Adminship and tweaked it a bit to make it relevant to Wikidata. Feel free to polish it... --Jakob (talk) 01:42, 25 February 2014 (UTC)

Proposed Properties

There hasn't been much activity on the Wikidata:Property proposal pages and these need to be tidyied up with old proposals either approved or rejected. I can't do it because I have voted on so many of these. Anyone else who want to voice an opinion or just see how we decide what to use and what not to should go have a look. Filceolaire (talk) 06:34, 25 February 2014 (UTC)

Range for numbers

For Q12318598 I have been trying to set employees (P1128) to the range 50–99, by setting it to 75±25. There seems to be some automatic regularization that changes it to "80±30". What happens? Is this a bug or a feature? — Finn Årup Nielsen (fnielsen) (talk) 02:41, 19 February 2014 (UTC)

It's rounding to the nearest value of 10. And I do not know why. @Lydia Pintscher (WMDE): Looks like a bug? --Izno (talk) 03:03, 19 February 2014 (UTC)
This is mixing two different things that should not be mixed. A range and an uncertainty. What the UI currently allows you to enter is the uncertainty. --Lydia Pintscher (WMDE) (talk) 08:28, 19 February 2014 (UTC)
Lydia, I agree with your statement, but how is it relevant? If the uncertainty happens to be +-25 for a number 75, how would I go about entering that with this seeming bug? --Izno (talk) 13:01, 19 February 2014 (UTC)
There is an accurate number of employees for Isabella at each point in it's existence, even if that number is not known. A range is not appropriate. Some days it was 50, some days it was 100. I would multiple values for this property, then go back and add the P585 qualifier property to make clear what date each number applies to.
Which is still irrelevant to the apparent bug. Am I not making myself clear? --Izno (talk) 14:48, 19 February 2014 (UTC)
Sorry @Izno: My reply was to the original query from @Fnielsen:. Filceolaire (talk) 17:51, 19 February 2014 (UTC)
I will look into the rounding issue. --Lydia Pintscher (WMDE) (talk) 13:32, 20 February 2014 (UTC)
The range 50–99 is the data given by the official database of Danish companies (CVR). The number of employees are specified in ranges. In some cases it might be possible to identify a more exact number on the company homepage, but then again it might not be exact. I have seen examples such as "almost 260" that I would presumable translate to "255±5". So qualifiers seems not to be the right solution (although the point in time (P585) can of course be used to specify when the data was lookup in CVR, but this is an unrelated issue). — Finn Årup Nielsen (fnielsen) (talk) 12:25, 21 February 2014 (UTC)
Does the license for the CVR database allow you to copy this? I suspect it doesn't as it is protected by the European database rights. All we are allowed do is link to the CVR item. 18:22, 22 February 2014 (UTC)
There are no problems with copying a single item. -- Lavallen (talk) 18:55, 22 February 2014 (UTC)
I believe the CVR authority is ordered by law to collect these data. If I remember correctly legal entities that must collect data has no database right. Furthermore, in 2012 the government of Denmark made a series of official data open: Privat persons and companies can use some data for non-commercial and commercial applications [7]. Rereading the material I do not see any explicit mentioning of the license though., e.g., whether it is irrevocable — Finn Årup Nielsen (fnielsen) (talk) 10:43, 25 February 2014 (UTC)

Academic journal database

JVbot has finished importing the ERA journal lists, so Wikidata now has at least 25000 academic journals with ISSNs, titles, etc. I have 'wasted' many hours avoiding creating duplicates of articles about journals that already exist on a Wikipedia, so I can also say that Wikipedia has approx 5000 articles of the ~15000 journals on the ERA 2010 journal list. I havent done an analysis of the Wikipedia coverage of the ERA 2012 journal list, but it should be roughly the same. See Wikidata talk:Periodicals task force#ERA journal lists imported for more info. fwiw, I have a financial conflict of interest with every one of those bot edits as I provide research assessment and management services to customers. John Vandenberg (talk) 01:55, 25 February 2014 (UTC)

Thank you John. This is really good work. Filceolaire (talk) 06:36, 25 February 2014 (UTC)
Thank you for your honesty, but I would have liked to read about you "financial conflict" before you promoted Scopus etc. --Kolja21 (talk) 06:54, 25 February 2014 (UTC)
Scopus is relevant information. The criteria for linking to external sources is that those external sources are relevant. I have no interest and I blogged arguing for the inclusion of scopus data. Thanks, GerardM (talk) 07:46, 25 February 2014 (UTC)
We talking about two different things. I'm not concerned about WD:N, but about neutrality and independence. If employees of companies pushing their content it is giving their products (like paid content) a clear advantage. It's the same as beeing paid for writing an article, even if this article contains striktly relevant information. --Kolja21 (talk) 09:23, 25 February 2014 (UTC)
I do not promote Scopus, and I am not employed/paid by Scopus or any related entity. If I was paid by Scopus, that would be a COI that needed to be disclosed each & every time I mentioned Scopus. (p.s. I have been active in the protests against Elsevier) I am an independent consultant. Wikidata needs a good periodical database, and I hope it will eventually become more useful than the many journal registries online - to do that, it needs lots of attributes, esp. discipline specific attributes like abbreviations used in different citation styles and links to other databases so people can connect their own data to Wikidata (and that link will usually be only possible if we have Scopus IDs). I have a large amount of privately curated research management data which is all linked together. I am trying to export the public/free data into Wikidata, wherever Wikidata wants it. I am essentially helping my potential competitors, if they want to learn Wikidata ;-) The benefits to me is that I dont need to maintain the data privately, as I can extract it out of public dumps if I ever need it, and the public data will grow in ways that I find useful. John Vandenberg (talk) 12:28, 25 February 2014 (UTC)
Thanks for the clarification. --Kolja21 (talk) 16:04, 25 February 2014 (UTC)

Want to do outreach for Wikidata as part of the Outreach Program for Women?

Hey folks :)

It is time for GSoC and the Outreach Program for Women again. We'll not be taking part in GSoC this round because I can't make sure we have adequate mentoring capacity for coding projects. However I am offering a non-coding project as part of the Outreach Program for Women. I'd love to see many applications. More details at mw:Outreach Program for Women/Round 8#Wikidata Outreach. --Lydia Pintscher (WMDE) (talk) 11:35, 25 February 2014 (UTC)

Is it possible to search for "Pressburger, Chava" in the deleted pages?

Hi! I started to contribute to Wikidata beginning of October 2013. Now I reached more then thousend contributions. I might suffer from schizophrenia (Q41112) but I see more and more contributions missing. During this night and day work my computer crashed a lot, it crashed over and over. Maybe I did not save what I intended to do. Maybe it is possible to let me know all pages I created which are deleted now. Thanks in advance! לערי ריינהארט (talk) 09:16, 14 February 2014 (UTC)

(Moved from Wikidata:Requests for comment/Is it possible to search for "Pressburger, Chava" in the deleted pages?)--GZWDer (talk) 12:35, 25 February 2014 (UTC)

Are you looking for Chava‏ Pressburger (Q15055703)? --Pasleim (talk) 12:57, 25 February 2014 (UTC)

Accessing history file of archived data for page count statistics

If anyone has experience enough to explain an easy way to access the historical data in the archives of the page count histories for Wikipedia articles by quality-rating and by importance-rating. I am presently doing a trend analysis study of relative growth rates according to quality if someone knows an easy way to access the historical data. This is the current version of the data table which works on Wikipedia (answer on my Wikipedia Talk page is fine also): en:Wikipedia:Version 1.0 Editorial Team/Statistics LawrencePrincipe (talk) 17:25, 25 February 2014 (UTC)

Incorporating Sunlight Foundation data

I am working with the Sunlight Foundation, a nonprofit organization based in Washington, DC, on an upcoming two-day event focused on using its API data to improve Wikipedia. The APIs operated by Sunlight contain objective, reliable data pertaining to the U.S. Congress and the various state legislatures. To the best of my knowledge, this is public domain data. My original thought was that we could use this data to populate Wikipedia infoboxes or use it as source material for Wikipedia articles—using a bot to keep the data fresh—but wouldn't it make more sense to incorporate it into Wikidata?

First of all, am I totally off base for recommending this? Should we just stick to Wikipedia? I am not totally familiar with Wikidata's rules, so I'd like input from the community first. If there is a chance we can work with Wikidata on this project, I need to know what we will need to do. Presumably we won't know exactly what kind of data we will want to incorporate until the event itself (April 5–6), but let's say we want to add data pertaining to members of the state legislatures (terms of service, political party, etc). Is there a manifesto of what data properties are currently registered for a given item and a process for amending that list? What are the ground rules—when is information useful, and when is it trivial? Any information on this would be very helpful.

I look forward to hearing your thoughts. Harej (talk) 21:17, 24 February 2014 (UTC)

Your thoughts are obscene and should never have been aired here.
That said, yes, it would be a good idea to bring it in here. Probably the biggest questions we would have would be: What data do you have (we will eat all of your data) and what is the actual license and copyright status of the data?
You might also consider Wikidata:WikiProject:Sunlight Foundation or similar. --Izno (talk) 01:06, 25 February 2014 (UTC)
The license is a real issue - under European law a database of facts is copyright and 'systematically' copying the facts is infringement. We need your database to be CC0 before we can take the info.
In the meantime we can create an authority control property to link Qitems here to the corresponding item there. This should go on the Wikidata:Property_proposal/Authority_control page. Ask back here or my talk page if you have any trouble creating the proposal. Filceolaire (talk) 06:46, 25 February 2014 (UTC)
The license is not the real issue. What is needed is for the copyright holder to the database to allow for publication of their data in Wikidata under a CC-0 license. When the license is already CC-0 this is implicit. Thanks, GerardM (talk) 07:43, 25 February 2014 (UTC)
@Harej: To go back to your other questions:
Existing Wikidata properties for politicians and elections
As noted above we have items describing elections and we have items describing persons and we use different properties for data related to each of these. We also have lots of items on political parties and all sorts of other organisations that data on political donations (for example) might be added to.
Wikidata is the place to put this data, this will make it easy to use in every one of the 280 different language wikipedias. With a bit of localisation on Wikidata the data can also be accessed by the Reasonator. This can be localised in any language, not just the 280 languages with wikipedias so this includes, for instance, Indian tribal languages that do not have a wikipedia yet.
Hope this helps. Filceolaire (talk) 08:13, 25 February 2014 (UTC)
Thank you all for the feedback. Regarding copyright, Sunlight appears to make its data available under CC0-esque terms, except for the Influence Explorer, so we'll just avoid using that. Re. authority controls: there are actually a lot of different control numbers used by different watchdog organizations, and Sunlight keeps a database of them all, so that's a potential property. Anyways, all of this is very exciting and I'm looking forward to a constructive relationship. As more things come together I'll create a project-space page to keep track of this work. Harej (talk) 02:34, 26 February 2014 (UTC)

Russia (Q159) model

I see something like

... It seems not to make sense, we should discuss this. The composed of qualifier here does not seem to be right as it qualifies the Russian government, so it should be a property of the governement item. Plus the executive body (P208) property should be valued by an actual instance of a Russian government, not the class (and definition) of all Russian government. It seems a pretty bad model we got here. TomT0m (talk) 21:28, 25 February 2014 (UTC)

EDIT : forgot to mention the composed of ... a date ???

Absolutely agree. That information should be on the item about the executive body. Some users just go haywire with adding unnecessary information in their qualifiers. --Izno (talk) 00:27, 26 February 2014 (UTC)

universities with affiliations; organizations with affiliations

Hi! en:Vilnius University Vilnius University (Q658192) is using property member of (P463). I s this OK?
en:List of Esperanto organizations is listing National associations linked to the UEA. Can property member of (P463) be used here?
I would not use part of: part of (P361) for national organizations. Only organizatorical structures as the board, the committee etc. לערי ריינהארט (talk) 22:41, 25 February 2014 (UTC)

(Moved from Wikidata:Requests for comment/universities with affiliations; organizations with affiliations; @לערי_ריינהארט:Requests for comment is not for general discussion. If you want to, for example, ask a question, please use here instead.)--GZWDer (talk) 10:03, 26 February 2014 (UTC)

Translations of MediaWiki:Searchmenu-new

Could someone create MediaWiki:Searchmenu-new/pt and MediaWiki:Searchmenu-new/pt-br with

Você pode {{#if:{{NAMESPACE:$1}}|criar a página [[:$1]]|[[Special:CreateItem|criar um novo item]]}}, mas considere verificar os resultados de busca apresentados abaixo para ver se o tópico já foi coberto. Você também pode [[Special:ItemByTitle|pesquisar itens do Wikidata por título]] e código de idioma.

Thanks! 14:29, 26 February 2014 (UTC)

  Done. --Yair rand (talk) 16:48, 26 February 2014 (UTC)


There are two entries for Heinz Spoerli and Renato Zanella, --Gerda Arendt (talk) 16:57, 26 February 2014 (UTC)

I   Merged them; see Heinz Spoerli (Q125026) and Renato Zanella (Q2143643). Thanks, The Anonymouse [talk] 17:15, 26 February 2014 (UTC)

from Template talk:Reply to missing support for spaces in user names

re: substitution of spaces with underscores required
Hi! @לערי_ריינהארט Long time ago I selected a user name containing a space to test this functionality WikiMedia wide. This template needs a fix. לערי ריינהארט (talk) 18:46, 26 February 2014 (UTC)


Is it a good idea to add ethnic group (P172) => Q841351 to items linked to articles in the Afrikaner people category on the English Wikipedia? Do we have a guideline on when it is appropriate to add a person's ethnicity more in general?--Underlying lk (talk) 12:49, 25 February 2014 (UTC)

So are the Cape Coloured Afrikaner people? They speak Afrikaans. Better to record what a persons native language/mother tongue is or was and avoid the ethniciity issue.
I see Barack Obama has been given ethnic group (P172):Afro-American even though neither of his parents were Afro-American (one was african, the other American or maybe Irish-American. Afro-American is a group that has been living in the USA for years. Michelle Obama's family are Afro-American). Ethnicity is to often POV. I don't like it. (Going off to change the Barack Obama item now.)Filceolaire (talk) 10:03, 26 February 2014 (UTC)
As ethnicity is self defined (at least since the denouncement of race biology in the middle of the last century), available categories will vary largely from place to place. I doubt the result of adding such a property would be very useful. Rotsee (talk) 10:42, 26 February 2014 (UTC)
I'm not sure about the utility of this either, but as a general rule I prefer to add a claim rather than not adding it. But given the sensitivity of the topic, I agree that it might be better to avoid adding this particular property.--Underlying lk (talk) 02:03, 27 February 2014 (UTC)

Date formatting


Is it possible to format the date "junho 12 1990" on this item as "12 de junho de 1990"? 14:05, 26 February 2014 (UTC)

I think the formatting is automatic and can only be changed by the developers. Maybe someone should file a bug report for this. The Anonymouse [talk] 17:30, 26 February 2014 (UTC)
Ok. I requested this on bugzilla:61958. 20:37, 26 February 2014 (UTC)

named after (P138) chains

Time for a bit of fun. Things get named after other things. Two examples:

Bit of a challenge: What's the longest chain we can find? Multichill (talk) 10:46, 22 February 2014 (UTC)

That would be a fun query for the database because I can't think of a longer chain. --Tobias1984 (talk) 10:19, 23 February 2014 (UTC)
I think I have a longer one here:
Klara norra kyrkogata (Q10546043) => Klara church (Q1540683) => St. Clare's Priory, Stockholm (Q7587608) => Clare of Assisi (Q191107)
ℇsquilo 12:20, 23 February 2014 (UTC)
@Multichill, Tobias1984, Esquilo:497 items with length>=2 chain.--GZWDer (talk) 15:45, 23 February 2014 (UTC)

Are interproject links accessible?

Now that Wikisource is fully integrated into Wikidata, I am curious if there is a way to access the other projects. i.e. Can I access the name of the English Wikipedia article from a page on English Wikisource (if both have the same data item)? In a similar sense, is there a way to just return the Q-number of a page rather than a property (or, failing that, some way to automatically check if a page is linked to Wikidata or not)? Thanks, AdamBMorgan (talk) 12:16, 26 February 2014 (UTC)

Templates could do the trick, the authority control already links to authority databases ... TomT0m (talk) 12:21, 26 February 2014 (UTC)
Yeah Lua gives you access to all data. What are you trying to do though? Tpt is working on bugzilla:54374 at the moment. --Lydia Pintscher (WMDE) (talk) 13:41, 26 February 2014 (UTC)
I'm thinking about part-automating the {{author}} page header. At this stage, I'm just curious about what I could actually do and what my options are. For the second part: it would be useful to have a tracking category for pages with no matching wikidata item. - AdamBMorgan (talk) 13:56, 26 February 2014 (UTC)
@AdamBMorgan: on it.wikisource, I've just set up s:it:Modulo:Autore and s:it:Modulo:Controllo di autorità to take advantage of Wikidata. For the second part: try s:Special:UnconnectedPages. --Ricordisamoa 16:44, 26 February 2014 (UTC)
Are there any help pages for this stuff? I've tried looking on Wikidata, Wikipedia and Meta but I haven't found anything (except a little about interlanguage links). I've looked at modules in other projects to find out which bits I need to steal, but I'm still not 100% clear on this stuff. None of them seem to be able to get the Wikipedia or Wikivoyage links, just the properties. s:Special:UnconnectedPages is useful but limited (I can't filter on a namespace, for example, or by date of entry). Just pulling the Q number (without any attached property) would be ideal, as I could both make a link and add a category, which could then be separately manipulated by, for example, a dynamic list. - AdamBMorgan (talk) 21:02, 26 February 2014 (UTC)
@AdamBMorgan: see mw:Extension:Wikibase Client/Lua. If you need help to create/improve Scribunto modules for Wikidata, just ask me! --Ricordisamoa 00:08, 27 February 2014 (UTC)
@Ricordisamoa:, I've read that page but it's not really helping to clear this up. Everything seems to refer to properties and statements, or it takes an item ID but doesn't return the item ID. I also can't see anything that would just return a link to Wikidata/Wikipedia/Wikivoyage/Commons/Wikisource. One part of what I want is the following:
If IsLinkedToWikidata = TRUE
The second is essentially {{#property:English Wikipedia}} or {{#property:English Wikivoyage}}. However, the content under, for example, "Wikipedia pages linked to this item" doesn't seem to be a property in the same sense as the content under "Statements" (or is accessed by a different name that I don't know). There doesn't seem to be any documentation anywhere in Wikimedia about extracting this data. - AdamBMorgan (talk) 14:18, 27 February 2014 (UTC)
Nevermind the latter, entity:getSitelink( 'enwiki' ) will do that, but I still can't see a solution to the part I thought would be the simplest: detecting whether or not a page is linked to a data item. - AdamBMorgan (talk) 14:49, 27 February 2014 (UTC)
Have you seen mw:Extension:Wikibase Client/Lua? If mw.wikibase.getEntityObject() return nil, the wikipedia article is not connected to wikidata. Otherwise, the entity you get is the data structure corresponding to the json object of the item, see for example [8].
    entity = mw.wikibase.getEntityObject()
    if entity then -- true if item connected
    	x = '- '
    	for a,b in pairs(entity) do  -- prints first order keys
    		x = x .. a .. ' - '
	if entity.type then -- prints the value of first order key "type" (should always be item in this case)
		x = x .. ' type: ' .. entity.type
	if then -- prints the value of the first order key "id" (Q12345)
		x = x .. ' id: ' ..
    	return 'entity found ' .. x
    	return 'no entity connected'
 — Felix Reimann (talk) 15:48, 27 February 2014 (UTC)

Powerplant P516 need fixing

powered by (P516) needs quite some work. Can someone please look at this discussion. I want to fix it, but I don't know where or how to start. Rehman 14:14, 27 February 2014 (UTC)

Road Signs (UK)

Firstly -

I'd like to transcribe the data here - into appropriate fields, (as well as providing cross references to related diagrams)

Suggestions on how to do this would be appreciated.ShakespeareFan00 (talk) 15:22, 26 February 2014 (UTC)

For the signs

  1. image (P18) to link to the commons image
  2. new 'Height' property for the allowed values for the height of the sign
  3. New 'Text size' property for the allowed values for the height of the text

For the additional info you need

  1. Regulations - new property with Item datatype (points to the item for the legislation). Can be used with any item to indicated the laws governing that item. Use with section, verse, paragraph, or clause (P958) as a qualifier for the appropriate clause (as many section, verse, paragraph, or clause (P958)s as there are clauses listed here). and additional qualifier 'instance of (P31):Regulations' where 'Regulations is a new Qitem.
  2. Directions - same as 1 above with additional qualifier 'instance of (P31):Directions' where Directions is a new Qitem.
  3. Diagrams - needs a new 'Associated item' property linking to the item for the other sign.
  4. Permitted Variants - as item 1 with added qualifier 'instance of (P31):Permitted Variants'
  5. Illlumination requirements - as item 1 with additional qualifier 'instance of (P31):Illumination requirements'
  6. Each statement should have a reference with properties stated in (P248), section, verse, paragraph, or clause (P958), reference URL (P854)
Four new properties overall but all properties which can be used much more widely than this project. OK? Filceolaire (talk) 18:18, 26 February 2014 (UTC)
  Comment 2/4 and 5 : no need to qualify the regulation property, just directly create properties "direction/.../...", it does not seems to be a qualification of the regulation, it is a property of some actual sign. TomT0m (talk) 19:24, 26 February 2014 (UTC)
@TomT0m: If you look at the legislation linked by @ShakespeareFan00: items 1, 2, 4 and 5 are all links to particular clauses in the legislation - e.g. 2 covers the clauses that cover Directions on how to use the signs. Creating 4 different properties for these seems redundant. Filceolaire (talk) 00:30, 28 February 2014 (UTC)
Thank you, I was going to suggest the following as additional data.
  • Start date - Date introduced
  • End date - Date of abolition... ( The actual "Instrument" mention 'savings' which I don't expect non UK people to follow)
  • Equivalent - Does the meaning of this sign exist in other jurisdictions?
  • Language variant - Yes there are Welsh language signs for example (and Gaelic ones). ?

Any other thing which could add 'useful' data? ShakespeareFan00 (talk) 20:22, 26 February 2014 (UTC)

full work available at (P953). Filceolaire (talk) 00:44, 28 February 2014 (UTC)

Help:Data type

Help:Data type is very out of date (I already did some work). Should we delete Boolean from the list? Does anybody know how many digits the quantity data type can store? What is the smallest and what is the largest number? Also will the time data type ever support time of day? --Tobias1984 (talk) 17:54, 26 February 2014 (UTC)

Boolean is out - it has effectively been replaced by instance of (P31) plus the appropriate Qitem.
We already have url (or is it technically IRI?)
When CommonsData happens we will want to link to Commons:Qitem not MediaWikiTitle.
Quantity with Dimension is no more odd than coordinate with globe (every coordinate has a hidden parameter telling if it is on earth, the moon, Mars or Io. I want them to add the celestial sphere for star positions).
OK? Filceolaire (talk) 18:29, 26 February 2014 (UTC)
"Quantity with dimension" is a weird name for the data type. I am not sure why it was adapted. The term "physical quantity" would be much more fitting. --Tobias1984 (talk) 18:38, 26 February 2014 (UTC)
I thought "Geographic shape' was on the pending list or has that been replaced by OSM relation ID (P402) (which links to OSM geoshapes). Filceolaire (talk) 01:12, 28 February 2014 (UTC)

Motte-and-bailey vs. Stronghold

I suspect Q92062 is essentially the same as Q57831 with the difference being primarily in English. "Stronghold" is pretty vague in English, whereas Motte-and-bailey is very specific. I discovered the oddity by looking for the English word for Czech tvrz. I'm brand new to wikidata, else I might perform a merge. That, and I have no familiarity with any of the other translations. -- Ke4roh (talk) 15:31, 27 February 2014 (UTC)

motte-and-bailey castle (Q92062) has sitelinks to 25 different Wikipedias. Even without speaking any of those languages I can see that the page names nearly all mention mot or motte or something similar. This doesn't look, to me, like one of those cases where the English page is different from the others. Filceolaire (talk) 01:55, 28 February 2014 (UTC)
I changed the English label to fortress (from stronghold) for fortress (Q57831), given that is the best translation of the title of the German article "festung". There is no fortress article on English wikipedia, only Fortification. Danrok (talk) 04:49, 28 February 2014 (UTC)

New code, speed, Wikisource and more

Graph showing the time it takes to load a large item on Wikidata before and after significant improvements.

Hey folks :)

We have just deployed new code. The most important changes are:

  • We cut down loading time of items significantly. Have a look at the graph. We're not done yet with performance improvements but this is already a huge step.
  • Wikisource now has access to the data on Wikidata via the property parser function and Lua.
  • We have extended the Lua interface significantly to make it easier to use Wikidata data in Lua. Hoo will publish more info about this soon. If you can't wait the documentation is up at mw:Extension:WikibaseClient/Lua. (To use it on Wikipedia you will have to wait until Thursday!)
  • Bugfixes

Cheers --Lydia Pintscher (WMDE) (talk) 19:54, 25 February 2014 (UTC)

Great news! :) Thanks for the update!--Micru (talk) 19:57, 25 February 2014 (UTC)
What is next on Wikidata:Development plan? --Tobias1984 (talk) 20:17, 25 February 2014 (UTC)
We will be doing more performance improvements. After that UI redesign, queries and Commons. --Lydia Pintscher (WMDE) (talk) 21:10, 25 February 2014 (UTC)
Thanks, but I still cannot open Zürich (Q72)... =( — Ayack (talk) 20:26, 25 February 2014 (UTC)
It does load fine here. But as I said we are not done yet. --Lydia Pintscher (WMDE) (talk) 21:10, 25 February 2014 (UTC)
And I believe(!) that on my tablet (Opera Mobile on Android 4.0) loading times significantly increased now. Previously, there have not been serious problems as far as I have been aware of, while now loading big items here starts to take a lot of patience. --YMS (talk) 20:46, 25 February 2014 (UTC)
Hmmm I'll give it a try. --Lydia Pintscher (WMDE) (talk) 21:10, 25 February 2014 (UTC)
As Ayack said, trying to open Zürich (Q72) still freezes my browser with no chance of recovery.--Underlying lk (talk) 21:03, 25 February 2014 (UTC)
As I said we are not done. --Lydia Pintscher (WMDE) (talk) 21:10, 25 February 2014 (UTC)

I can't see on item page anymore if some item linked on page has been deleted, I mean Deleted item text. I added deleted item but there's no that text. --Stryn (talk) 21:18, 25 February 2014 (UTC)

That's bugzilla:61854. Will most likely be fixed in the next deployment. It is set to critical already and in the current sprint. --Lydia Pintscher (WMDE) (talk) 21:24, 25 February 2014 (UTC)

Some qualifiers and sources aren't being displayed properly. For example, coat of arms (P237) for Russia (Q159) shows a date for a main regulatory text (P92) qualifier. When I click edit, it displays the normal value. --—Wylve (talk) 14:24, 26 February 2014 (UTC)

We'll deploy a fix for that in the next hours probably. bugzilla:61943 --Lydia Pintscher (WMDE) (talk) 14:38, 26 February 2014 (UTC)
This was fixed by the way. Just forgot to ping here. --Lydia Pintscher (WMDE) (talk) 10:00, 28 February 2014 (UTC)

MediaWiki hackathon in Zurich

From 9th to 11th of May there will be a MediaWiki hackathon in Zurich. Scholarships are available for this and some of them are given out by Wikimedia Germany for MediaWiki developers who are from Germany or work on Wikidata or the migration of tools from Toolserver to Tool Labs. You can apply for a scholarship directly via the registration form for the hackathon. The registration deadline is 16th of March. I’m looking forward to seeing many of you there to work on Wikidata together. The whole Wikidata dev team will attend. --Lydia Pintscher (WMDE) (talk) 13:36, 28 February 2014 (UTC)

Heraldry/Coats of arms

Commons currently facilitates a complex system of detailed categories to classify coats of arms, for example commons:Category:Crossed horse heads in heraldry to collect all coats of arms that depict crossed horse heads as a gable decoration.

I guess we could build a Wikidata structure that is much more suitable and machine-readable to describe coats of arms.

I think of something like this example:

coat of arms of Wendisch Evern (Q654392):

image (P18): File:Wappen Wendisch Evern.png
color (P462): "blue" azure (Q1785501)
depicts (P180): "crossed horse heads"
color (P462): "silver" argent (Q936472)
quantity (P1114): 1
depicts (P180): "heart"
color (P462): "gold" or (Q430099)
quantity (P1114): 3
depicts (P180): "boar"
color (P462): "gold" or (Q430099)
quantity (P1114): 1

The colors (heraldic tinctures) need items of their own and we probably also need separate items for "crossed horse heads in heraldry", "hearts in heraldry" etc. (some of them already exist where wikis have articles on them: heart (Q1615029))).

Most heraldic colors already have items: instances of tincture (Q3404720) or its subclasses, from Category:Heraldic tinctures (Q8508640) and Template:Tincture (Q10990278). LaddΩ chat ;) 01:38, 26 February 2014 (UTC)

My idea implies that every existing coat of arms gets its own item and items about cities link to these items (instead of linking to the Commons image depicting the coat of arms), because an item can have several coats of arms over time.

What do you think. Is this a good idea, is it feasible? --Slomox (talk) 10:24, 25 February 2014 (UTC)

Instead of color (P462), I would recommend a distinct property "heraldic tincture" pointing to distinct tincture items. The tincture item argent (Q936472) has then instance of (P31) "metal" and color (P462) white (Q23444).  — Felix Reimann (talk) 11:08, 25 February 2014 (UTC)
It's a good idea. We already have some links to commons on Wikidata with the properties commons category, images ... However the integration of commons is not totally done yet and there have been propositions that the common file metadata will not be stored on wikidata but raher will stay on commons. But it seems that you propose is not to describe an image but a blason here so it seems OK to store the description of a blason here. A blason item is notable per WD:N if the organisation/family is he the blason of is notable, so there is no problem about that.
That said on the model itself it seems a pretty good start, however I know nothing about heraldic but I think there is already pretty well defined rules on how to describe a blason, did you follow them ? I think I already seen programs that draw the blason from a description automatically, if we could store that on Wikidata that would be great. TomT0m (talk) 11:17, 25 February 2014 (UTC)
@Lokal Profil:! -- Lavallen (talk) 17:43, 25 February 2014 (UTC)
We should avoid this here until such time as Commons can use the WikiBase client in a meaningful fashion. It's a great idea otherwise. --Izno (talk) 00:21, 26 February 2014 (UTC)
I disagree. If we can do it here, now, then I think there is no reason not to proceed. When Commonsdata happens we can look at what information we want to migrate into the image descriptions there and out of the ITEM descriptions here. Heraldic emblems are right on the cusp between the two projects. Wikidata should include all the info about the registered design and it's history and usage. Commonsdata should include all the info on the particular examples of that design which it has images of. IMHO. Filceolaire (talk) 07:08, 26 February 2014 (UTC)
WP already have many articles in this subject, so we should proceed! -- Lavallen (talk) 08:09, 26 February 2014 (UTC)
I did some testing of the concept by trying to describe several coats of arms. I guess, I'll run into problems when we would need qualifiers for qualifiers. In File:Arms of Winston Churchill.svg for example I cannot describe the four quarters because at least three levels of abstraction are necessary (Churchill's coa includes the Duke of Marlborough's coa which includes the coa of England). I can circumvent this problem when I just say "1st quarter depicts the coat of arms of the Dukes of Marlborough" instead of actually describing the contents of the Dukes' coat of arms. But there is no guarantee that all instances of complex fields are referencing coat of arms that have items of their own.
And in File:Brandenburg Wappen.svg I run into problems with the arming and charging of the eagle. The eagle is a property of the coat of arms and the arming and charging are qualifiers of this property. But what about the tincture of the arming and charging? It would need to be a qualifier of the qualifier. This can be circumvented by creating a separate property "tincture of arming of a heraldic charge", but that's a very specific property and that would probably mean creating many properties for all the nuances of heraldic blazoning.
And in File:PB Ostergotland CoA.png the griffin is blazoned as being "between" the four roses. I don't know of a good way to describe this relation between charges because we cannot refer to another property of the item. This is not a big issue in reality but it is a limitation and it means we cannot losslessly describe a blazon.
I hate it, when the complexity of reality destroys the nice ideas in my head ;-)
I still like the idea and it works for most coats of arms, but the cornercases crush the concept. :-/
For most use cases it would work but it seems unrealistic to cover all information present in blazons. --Slomox (talk) 08:51, 26 February 2014 (UTC)
@Slomox: Regarding Östergötland: I rött fält en gyllene grip med drakvinge och draksvans samt med blå draktunga och beväring, i vart av sköldens hörn åtföljd av en ros av silver. This does not thell that the griffin is between the silverroses, but rather that the roses are located in the corners. -- Lavallen (talk) 10:54, 26 February 2014 (UTC)
I see. Thank you for pointing it out. Classical error on my side. Never rely on translations. You are of course right. But I assume there are other examples where blazons make internal references. --Slomox (talk) 12:24, 26 February 2014 (UTC)
I think we can do this, if we stop trying to put everything in one statement. We can use several items. For example a cross (in heraldic) need it own class item, and can be instantiated with an item describing The cross of this blason. TomT0m (talk) 09:40, 26 February 2014 (UTC)
I'm with Slomox on this. In order to get useful descriptions you would either need nested statements (i.e. where the qualifier of a statement is itself another statement). Or we would have to create individual entities for any moderately complex bits of a blazon so that these could be referenced in the main blazon. Or we can collect extremely basic information on the CoA which could not be used to recreate the blazon. As an example consider describing a shield which is quartered and where one of the quarters is in turn quartered again (and where every field has a charge).
On the other hand I definitely agree that if attempted then Wikidata is the place to do it, not Commons. This is a property of the Coat of Arms (blazon + it's history). The image on Commons is merely an illustration of what this might look like. /Lokal Profil (talk) 22:45, 28 February 2014 (UTC)
Clarification: I'm with Slomox on this when it comes to a) using entities for CoAs instead of pointing to the image (this can be done from the CoA entity). b) complex cases will not work with the above model. My suggestion would be to use a more simplistic model i.e. only used in a similar way to the current Commons categories (i.e. don't expect it to be able to generate blazons). This would allow us to define relations e.g.
  • Arms of Winston Churchill's CoA includes Duke of Marlboroug's CoA
  • Östergötland's CoA charged with griffin (or, 1), roses (argent, 4) on field=gules
  • Skellefteå landskommun's CoA is Party per fess (wavy, 1), field=gules, field=argent, charged with rose (2, argent), rose (2, gules)
/Lokal Profil (talk) 23:02, 28 February 2014 (UTC)
In my opinion the approach through text will not work well, because the information is more of a map. And a map is the best way to handle this information. If the coat of arms can be divided into polygons, then the polygons could hold individual statements. I know that en:PostGIS has been used to describe uncommon maps like information on thin sections and petri-dishes. @Lydia Pintscher (WMDE): Can we make the polygon datatype versatile enough to store semantic statements for geometries (that don't necessarily have to be on the Earth's surface). Maybe there is also a Semantic-Web-SVG? I somehow think that it would be easy to nest the two mark-up-languages? --Tobias1984 (talk) 09:41, 26 February 2014 (UTC)
There is already probably a svg file on commons, what you seems to be describing is a vector graphic representation. But see Q15300809, heraldic have formal rules to define a blason, It's more interesting to see if we can store them in Wikidata in a good way :). TomT0m (talk) 10:10, 26 February 2014 (UTC)
I'm not sure what you're trying to do. Currently it's not planned to have the geoshape datatype be usable for something else than geoshapes. But if there are actual valid usecases we'll need to consider them. Maybe with another datatype though. --Lydia Pintscher (WMDE) (talk) 11:35, 26 February 2014 (UTC)
Province of Östergötland have today the same CoA as the County of Östergötland. But the province-coa have a much longer history. Any ideas of how to solve that? -- Lavallen (talk) 11:03, 26 February 2014 (UTC)
If they are identical we could create one item for both and both our items Östergötland (Q214829) and Östergötland County (Q104940) would refer to this item (both with qualifiers about the time frame they used the coat of arms).
Perhaps you see further problems. I don't see them at the moment. Please elaborate if I miss issues. --Slomox (talk) 12:36, 26 February 2014 (UTC)
From what I understand from the Swedish articles: The Province had historicly two CoA's (from 16th century), they were merged and modified to what it looks like today (a dragon and a lion turned into a griffin), and the blue colors were added in the 1970's. But the county's CoA have never looked anything else than it does today, it was introduced in the 1970's. -- Lavallen (talk) 15:20, 26 February 2014 (UTC)
That would mean we have to create four items for the four different versions of the coat of arms. Östergötland County (Q104940) would reference the current one (with time qualifiers "1970s" until "current") and Östergötland (Q214829) would reference all four with respective time qualifiers "16th century" until "1884" (two times), "1884" until "1970s", and "1970s" until "current" (or whatever the correct time frames are).
Each time a bearer of a coat of arms changes its coat of arms we need to create one more item. --Slomox (talk) 07:47, 27 February 2014 (UTC)
Sounds fair. Härjedalen Municipality (Q513421) is another tricky example. They uses the same CoA as the Province of Härjedalen, but they do not own it. They have been denied the right to use the the same CoA as the Province, but they are still using it. -- Lavallen (talk) 10:12, 27 February 2014 (UTC)

What are the phases of Wikidata and what is each one?

Hello everybody. I have seen many times in project chat and some other project pages the text «Phase I», «Phase II», or even «Phase III»; and I wonder what a «phase» is. I have a vague idea that they are stages of implementation of Wikidata/Wikibase in whole Wikimedia, but I do not know what things have implemented each one. Can anyone tell me more about this? It would be good if we write a subpage of glossary explaining this. Greetings. --Zerabat (talk) 16:51, 28 February 2014 (UTC)

Phase 1 was where we collected links to Wiki(p|m)edia articles. Phase 2 (where we are now) is the addition of statements to Wikidata items so that (at some point) the other wikis can use our data. Phase 3 will happen when queries are supported. --Jakob (talk) 16:54, 28 February 2014 (UTC)
See also Wikidata:Introduction#Timeline of deployment on Wikidata. HenkvD (talk) 19:41, 28 February 2014 (UTC)

Call for project ideas: funding is available for community experiments

I apologize if this message is not in your language. Please help translate it.

Do you have an idea for a project that could improve your community? Individual Engagement Grants from the Wikimedia Foundation help support individuals and small teams to organize experiments for 6 months. You can get funding to try out your idea for online community organizing, outreach, tool-building, or research to help make Wikidata better. In March, we’re looking for new project proposals.

Examples of past Individual Engagement Grant projects:

Proposals are due by 31 March 2014. There are a number of ways to get involved!

Hope to have your participation,

--Siko Bouterse, Head of Individual Engagement Grants, Wikimedia Foundation 19:44, 28 February 2014 (UTC)