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)
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 https://github.com/mkroetzsch/wda/blob/master/wda-export-data.py, with some modifications and enhancements.
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:
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 publication of scientific name for taxon (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)
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)
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)
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)
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:
Is it appropriate to use instance of (P31) as an ad hoc qualifier when no specific qualifier/property is available?
Could we express the information in this special case in a better way?
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*talk12: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*talk16: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*talk19: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)
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.
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)
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)
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)
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)
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)
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)
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)
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 http://suggester.wmflabs.org/wiki/index.php/Item:Q4. 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)
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)
[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)
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)
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)
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)
The usefulness of national team appearances (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)
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. — billinghurstsDrewth09: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. — billinghurstsDrewth11: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
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)
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)
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. /ℇsquilo07: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)
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!
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)
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)
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 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)
Workbench
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)
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 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)
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? /ℇsquilo19: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. -gerakitalk17: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)
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)
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)
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)
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)
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:
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.
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.
AND
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.
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)
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)
Q5455008
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)
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)
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)
Semantics
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)
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)
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.
@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)
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.
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 :
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.
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:equivalentClass>
<owl:Restriction>
<owl:onProperty rdf:resource="residence" />
<owl:hasValue rdf:resource="Paris" />
</owl:Restriction>
</owl:equivalentClass>
</owl:Class>
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:
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:equivalentClass>
<owl:Restriction>
<owl:onProperty rdf:resource="alma mater" />
<owl:hasValue rdf:resource="$school" />
</owl:Restriction>
</owl:equivalentClass>
</owl:Class>
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
EquivalentTo:
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.
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)
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.
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.
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
EquivalentTo:
residence value Paris
but also a second one :
Class: inhabitant of Paris Special properties
EquivalentTo:
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)
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)
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 or worldview (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, writers, or signers (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)
@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 & 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 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)
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)
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)
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: http://www.uniprot.org/taxonomy/9615.rdf. The second approach, used in Darwin Core, uses a 'parentNameUsage' property as described in http://rs.tdwg.org/dwc/terms/history/index.htm#parentNameUsage-2009-09-21, 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 semanticweb.com. 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?
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.
+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:
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.
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.
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.
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?
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)
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...)
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)
You can get most items with a country through a query for country (P17). Counties, see #2.
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.
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, 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)
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 commune 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)
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)
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)
In France, it's simplier : in 99 % of the cases we only have an article for the commune and the The National Institute of Statistics and Economic Studies (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.
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 ?
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)
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 ;)
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)
same items ppl+adimin division with different proprieties to maintain adherence with the majority of the wikipedia entries
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)
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)
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.
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:
Relabel the item to 'Mark William Calaway' and create a new item "The Undertaker"
Keep "The Undertaker", create a new item 'Mark William Calaway' and remove all statements which are referring to Mark William Calaway
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. /ℇsquilo11:45, 14 February 2014 (UTC)
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:
"Next item" in 1 (Q199)=>2 (Q200); (both 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:
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?
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)
@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
… 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
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.
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)
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
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)
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)
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
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)
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)
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 bugs.wikimedia.org 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)
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 edits15: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)
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)
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:
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)
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)
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)
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)
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
Logo
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
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 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)
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)
@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)
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)
@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) 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(s) (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
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)
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): 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)
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)
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 page19: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 page06: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)
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)
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)
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.
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)
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.
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)
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 infectious disease (Q131736), which is why I can't fix it. --Tobias1984 (talk) 21:54, 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)
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)
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)
@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)
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)
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)
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.
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. 212.113.130.11818:22, 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 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)
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)
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)
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/StatisticsLawrencePrincipe (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.
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?
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.
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)
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.
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)
... 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
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.
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)
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
Hi!
Is it possible to format the date "junho 12 1990" on this item as "12 de junho de 1990"? Helder.wiki 14:05, 26 February 2014 (UTC)
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)
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)
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)
@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
[[Category:Foo]]
Else
[[Category:Bar]]
End
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 .. ' - '
end
if entity.type then -- prints the value of first order key "type" (should always be item in this case)
x = x .. ' type: ' .. entity.type
end
if entity.id then -- prints the value of the first order key "id" (Q12345)
x = x .. ' id: ' .. entity.id
end
return 'entity found ' .. x
else
return 'no entity connected'
end
new 'Height' property for the allowed values for the height of the sign
New 'Text size' property for the allowed values for the height of the text
For the additional info you need
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.
Directions - same as 1 above with additional qualifier 'instance of (P31):Directions' where Directions is a new Qitem.
Diagrams - needs a new 'Associated item' property linking to the item for the other sign.
Permitted Variants - as item 1 with added qualifier 'instance of (P31):Permitted Variants'
Illlumination requirements - as item 1 with additional qualifier 'instance of (P31):Illumination requirements'
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). ?
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).
"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 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!)
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)
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.
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))).
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.
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)
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)
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. :-/
@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)
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 blazonry (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).
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).
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)
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:
Support There is also an outdated page User:Sk!dbot/disambiguation page conflict. Matěj Suchánek (talk) 19:53, 5 February 2014 (UTC)
Done I've corrected the edits. --Kolja21 (talk) 07:40, 4 February 2014 (UTC)
Done. TomT0m (talk) 16:58, 9 February 2014 (UTC)
. Plus, because there is lot of little communes in France, the commune and the ppl have almost the same population/altitude/etc.
in 
, which is why I can't fix it. --Tobias1984 (talk) 21:54, 18 February 2014 (UTC)
⟩ executive body (P208) 
Merged them; see Heinz Spoerli (Q125026) and Renato Zanella (Q2143643). Thanks, The Anonymouse [talk] 17:15, 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)
