Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Please use {{Q}} or {{P}}, the first time you mention an item, or property, respectively.
Requests for deletions can be made here. Merging instructions can be found here.
IRC channel: #wikidata connect
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2019/03.

Project
chat

Lexicographical
data

Administrators'
noticeboard

Development
team

Translators'
noticeboard

Request
a query

Requests
for deletions

Requests
for comment

Bot
requests

Requests
for permissions

Property
proposal

Properties
for deletion

Partnerships
and imports

Interwiki
conflicts

Bureaucrats'
noticeboard

Contents

Please block User:UU[edit]

He vandalised many interwikis about Planet X or Planet Beyond Neptune.  – The preceding unsigned comment was added by 2001:2d8:e290:9990::ba48:af02 (talk • contribs) at 16 February 2019‎ (UTC).

Let's talk about gender[edit]

The property sex or gender (P21) seems like it could use improvement.

The good: The property allows for an impressively diverse range of values including "two-spirit", "transfeminine", "agender", etc.

The bad: because the property only allows you to pick one single value, it is very inflexible. For example, when describing a woman you have to pick between "female" and "transgender female". This ghettoizes transgender people: the question of whether someone is female should be considered seperately from whether they are cisgender or transgender. Also, look at the case of Mauro Cabral Grinspan. Over on Wikipedia, sche pointed out to me that Grinspan identifies as transgender, male, and intersex, and all three are important parts of his identity as an activist and a human being. However, currently, P21 does not allow you to select all three. Instead you must choose between "transgender male" or "intersex". (Currently he's listed as transgender male.)

One obvious solution: allow multiple values. I found a report about cataloging gender that advocates this approach. Here is what that might look like:

Alternatively, instead of allowing multiple values, perhaps we could keep the one value constraint but open things up to qualifiers, to similar effect:

etc.

Note that in my view, strong preference should be given to current self-identification (as recorded in reliable sources). For example, a trans woman should not be listed under both "female" and "male" but just "female". The RDA cataloging standard, which I believe is considered pretty authoritative in the library world, has a similar view. It says, under "instructions for recording gender": Gender is the gender with which a person identifies.

Related to the above, my biggest fear with opening up the gender category like this is that editors will just indiscriminately slap both "male" and "female" onto practically any trans or queer person. Perhaps, to avoid this kind of "excessive gendering", it would be better to go with a single value + qualifiers approach.

Anyway, that's my two cents, but note I'm very new to Wikidata don't claim to be an expert on either cataloging or gender. :)

(*) Why didn't you list Shakespeare or Chastain as cisgender? While it would seem fairly reasonable to describe them as cisgender, if someone hasn't identified as such in a reliable source, perhaps it's best to leave it out. (Jeffrey Tambor, meanwhile, has publicly called himself cisgender.)

(**) Why did you list Rebecca Sugar as both nonbinary and female? Because she identifies as a "nonbinary woman". Again, self-identification is king. (...Or queen. Or monarch.)

WanderingWanda (talk) 03:05, 9 March 2019 (UTC)

Note: There's quite a bit of previous discussion at Property talk:P21. Just a thought: if we're going to use self-identification as a qualifier, we should try to use qualifiers that are commonly and consistently used (as we should for any label, really). I myself am a cis-gender male, biologically. I identify simply as male, even though I just said I am cis-gender one sentence ago, and my future identification might change depending on whether I'm speaking on chromosomes or gender studies. The majority of male and female humans in history probably are or were cis-gender. As far as I know, Jeffrey Tambor (Q320204) referred to himself as a cis-gender man exactly once in a speech directly related to him playing a transgender character. Does that mean Tambor "identifies as cisgender male"? Is that enough for a qualifier? I'd argue no, unless he regularly corrects people when they call him an unqualified man. But gender and sexuality are certainly fluid and complex. I'm no expert either, and perhaps the rigid granularity of Wikidata doesn't fully allow for proper record keeping in this field. Animalparty (talk) 05:44, 9 March 2019 (UTC)
Animalparty I understand what you're saying but I think you're coming at this from the wrong angle. I don't think someone's cisness disappears just because they don't talk about it. Same with someone's transness or maleness or femaleness or straightness or gayness or whiteness or blackness. I rarely mention the fact that I'm white, but that doesn't mean I'm not white! It's also worth noting that people in a dominant majority group will naturally talk and think about that group a lot less than people in a marginalized minority group. Anyway, in my view Jeffrey Tambor said he's cisgender, and he's never indicated he's not cisgender, therefore, I think it's perfectly reasonable to label him as cisgender. WanderingWanda (talk) 07:12, 9 March 2019 (UTC)
I'll add that the only reason I used the word "qualifier" is because that's the Wikidata terminology and I was a little uncomfortable using that specific word. (Hmm, perhaps the fact the word "qualifier" is a little uncomfortable in this case is a reason to avoid using qualifiers to solve this.) WanderingWanda (talk) 07:21, 9 March 2019 (UTC)
I think it would be better to have two different properties. One for the sex just defined by the chromosomes and one for gender defined by the person them self. --GPSLeo (talk) 11:10, 9 March 2019 (UTC)
How do you propose we get people's chromosome data, exactly? Is Wikidata going to start commissioning large scale blood tests? :) WanderingWanda (talk) 16:26, 9 March 2019 (UTC)
I would only differ in has a Y-Chromosom or dose not have it. Of course we do not have the data in most cases, but then we just should not imply that we have that information like it is now. --GPSLeo (talk) 17:28, 9 March 2019 (UTC)
Unlike blood type (P1853), we do not actually need blood tests to determine this. Property_talk:P21#Reasonable_inferences. --Yair rand (talk) 18:41, 10 March 2019 (UTC)
I was going to argue but....it seems like the decision to combine sex and gender was made years ago, do we want to relitigate it? I feel like I went "what if we made these tweaks" and you came in with "ah but what if we just throw out what we have and start over?" :) WanderingWanda (talk) 04:36, 11 March 2019 (UTC)
(Was this a reply to my comment, or GPSLeo's? I'm in favor of maintaining one unified property using the current format.) --Yair rand (talk) 06:23, 11 March 2019 (UTC)
I might have misunderstood your position. WanderingWanda (talk) 15:38, 11 March 2019 (UTC)
@GPSLeo: (Via edit conflict) Very problematic. Just for some examples:
In most cases we have no idea who has XYY syndrome (Q267602) rather than simply being male.
Most transgender people see it as insulting to focus equally on their biological gender.
If we really want to model this, there is also presentational gender, which may be multiple for the same person: consider drag performers. And drag performers also can bring up some interesting issues about self-identified gender. Most identify with their biological gender. Some are transgender. Some start by identifying with their biological gender, then become increasingly transgender-identified over time. Many prefer a different set of pronouns depending on their presentation at the moment. - Jmabel (talk) 16:30, 9 March 2019 (UTC)
I admit I don't know much about drag culture, so maybe this is the wrong way to look at it, but: if we wanted to model a drag queen's in-drag gender presentation, my thought is that it should essentially be treated as the gender of a fictional character, like the gender of Harry Potter. WanderingWanda (talk) 16:51, 9 March 2019 (UTC)
The way Wikidata currently treats drag queens seems fine to me, though. As it is now: the label is the performer's drag/stage name, and then the performer's less-well-known non-drag name is listed as an alias, and the gender is listed as whatever the performer currently identifies as outside of drag. So the drag performer Eureka O'Hara is listed with the alias "David Huggard" and the gender of "non-binary" (because the performer identifies as, according to Wikipedia, "genderfluid and gender-neutral.") Meanwhile Alexis Michelle is listed with the alias "Alex Michaels" and the gender "male" because apparently the performer identifies as male outside of drag. WanderingWanda (talk) 17:54, 9 March 2019 (UTC)

Technical question: is it possible to set things so that a statement can have multiple values but certain combinations of values are constrained? For example, could the gender property be set so that you can combine the value “transgender” with the value “male” but there’s either a hard or soft restriction on combining “male” and “female”? WanderingWanda (talk) 01:34, 10 March 2019 (UTC)

I would support allowing the property to have multiple values to cover these cases. An alternative would be to simply expand the number of values, so that besides "transgender female" one could have "intersex female", "cisgender female", "intersex transgender female", etc, but the number of such values would be large (consider that it already allows things like "kathoey" and "two-spirit", and any of these might co-exist with "intersex"), and besides there are the other aforementioned conceptual reasons (the distictness of being trans/cs from being male/female) that simply allowing multiple values would be more sensible. (I would oppose a "chromosomal sex" parameter, since for almost all people, the parameter would be guesswork, and why add a field for something you know going in is going to be unverified and unverifiable guesswork in the vast majority of cases? Perhaps something like "assigned sex", while still very problematic, would at least be somewhat less farcical... but in most cases, we only know someone's gender: whether they present themselves, dress, etc as a man, woman, etc.) -sche (talk) 22:19, 10 March 2019 (UTC)
No, it is actually quite possible to infer it. See the linked section above. --Yair rand (talk) 00:03, 11 March 2019 (UTC)

One more thing: The fact that Caitlyn Jenner and other trans people have a "start time" qualifier added to their gender feels off to me. Gender transition is a lifelong, multistep process and someone coming out as trans is best thought of as a reveal rather than a sudden change. Caitlyn Jenner may have announced that she was a woman on "1 June 2015" but that doesn't mean that's the official start of her womanhood. In fact, if you read the Vanity Fair article that is used as a reference for that "1 June 2015" date, you'll discover that Caitlyn Jenner's family had been discussing her gender for decades before she publicly came out. I recommend we create a new "coming out date" property and use that instead of "start time". WanderingWanda (talk) 23:54, 10 March 2019 (UTC)

See significant event (P793), although I think that would be supplementary data rather than a replacement for start time. Note that start date properties can have variable precision. --Yair rand (talk) 00:03, 11 March 2019 (UTC)
Maybe instead of "coming out date", I'll propose new property "announcement time". That could be used for a lot of different things, including the date when someone came out as trans, and could also, presumably, be made to allow for variable precision. WanderingWanda (talk) 04:15, 11 March 2019 (UTC)
Personally, I think using P793 in more cases has many advantages over creating different properties, although some think otherwise. See Wikidata:Properties_for_deletion#.7B.7BPfD.7CProperty:P606.7D.7D for an ongoing discussion mostly about whether P793 should be used instead of many separate properties. --Yair rand (talk) 06:23, 11 March 2019 (UTC)

Looking into things a bit more, "sex or gender" originally did allow multiple values, and, unfortunately, it resulted in exactly the "excessive gendering" problem I was worried about. At one point Chelsea Manning, for example, was listed as "male" and "female" and "transgender female". Yikes.

The way Wikidata handles gender now is problematic but it apparently is a big improvement on how things used to be. Suddenly I'm much less inclined to try and change things, lest they regress.

Still, I think opening the gender property back up to multiple values could allow us to paint a better, more accurate, and more nuanced picture of who a person is, if we worked towards the goal of reflecting and respecting a person's latest self-identification and shared the basic understanding that trans women are women and trans men are men. WanderingWanda (talk) 16:00, 11 March 2019 (UTC)

sex or gender (P21) is in some languages named now nonly "sex", as it was proposed years ago. Mixing two concepts is not good, there are tools (categorization, grammatical case, inflection etc.) which requires binary input - man/woman/other (not specified, unknown, special). Everybody was born as man or woman (And have this information in birth certificate (Q83900)), but some of them identify himself as something other. So I thing everybody should have Template:P21=man/woman (in special cases (deprecated?) with qualifier at birth) and these special cases can have second statement something other. JAn Dudík (talk) 07:31, 13 March 2019 (UTC)

  • No, actually [:en:Intersex|not everyone was born as man or woman]. For several percent, it's really a matter of gender assignment at birth. - Jmabel (talk) 15:45, 13 March 2019 (UTC)
  • The claim that multiple values aren't allowed on Wikidata for sex or gender (P21) is false. The one value constraint indicates that a property generally has only one value, but doesn't say that it's forbidden to have more then one value. There's nothing standing in the way of adding multiple values and qualifying them with start time (P580), end time (P582), subject has role (P2868) and similar properties to describe the status of the relevant claim. If you do make multiple claims, the constraint warning even goes away when you flag one of them as the "preferred value" (and it makes sense to use the most recent self-identfied value for that).
When it comes to "announcement time" feel free to propose the property with multiple examples from different domains where it would be useful. I don't think significant event (P793) is good as a qualifier for claims about when a claim started being true. significant event (P793) doesn't subclass point in time (P585).ChristianKl❫ 15:11, 14 March 2019 (UTC)
  • I could be wrong but I believe, when I first looked at the property, the one value constraint was set to mandatory. I do see that multiple values are currently allowed, however. WanderingWanda (talk) 03:27, 16 March 2019 (UTC)
In 2014 the constraint was first set to the current wording, because in cases like this it's useful to enter multiple values. When WMDE implemented the features that make constraints more visible they tasked an UX person with writing texts that explain the constraint that had no experience with using Wikidata. That UX person thought that the constraint should be mandatory and wrote corresponding texts. Unfortunately, they didn't check in with the existing Wikidata community about whether we want the constraint to be mandatory. It wasn't clear to the person that it's important to have the flexibility in cases like that. It was up a while in that wording till I changed it back to the original wording. ChristianKl❫ 11:04, 17 March 2019 (UTC)
I don't think setting start and end dates helps (some or all of) the cases we're talking about, unless it's considered sensible and acceptable for multiple Qs to cover the same period and for that period to sometimes or often be the individual's whole life. Indeed, the ability to set start and end dates in this case seems more liable to be misused, if someone wants to pick a moment (of whatever degree of precision) and say "before then this trans woman was a man" (which is ... fraught with problems), than to have a good purpose. I don't know that setting a "preferred" value and other values as less-preferred helps either, in cases like e.g. the aforementioned Mauro Cabral Grinspan, an intersex trans man who is both an intersex and a trans activist and thus might not see one of those as more primary/privileged than the other. The solution seems to be to set multiple values at the same top level of "preferred"-ness, and I'm pleased to see that this appears to be possible. (Now to see if the edits stick...)
The remaining question is, I suppose, whether to continue handling trans women with the "transgender female" label or to prefer using "female"+"transgender", the latter of which I am pleased to see seems theoretically/technically possible since Q189125 exists. :) -sche (talk) 07:12, 18 March 2019 (UTC)
I didn't said anything about setting values as less preferred. You might want to read up what the preferred rank happens to be within Wikidata. There are many cases where a data-consumer does want a truthy value of what someone's gender is. I consider it to be a resonable expectation for data consumers to treat properties that are tagged with 'single value constraint' as providing reasonable truthy values. Using "transgender female" has the advantage that this is a value that can be truthy while the combination of two labels would mean that only of of them would be returned when a data-consumer asks for a truthy value. ChristianKl❫ 12:37, 18 March 2019 (UTC)

Abuse, gender category[edit]

The gender property is being used to abuse transgender people by outing them as transgender, or to abuse people who are not transgender by assigning them as transgender. Malign editors are adding "transgender" without any reference to authoritative statements. How do you propose to address this? There is no recourse at the moment for people to remove such abusive categorisation.--Esterazy (talk) 16:04, 22 March 2019 (UTC)

@Esterazy: They can be summarily removed if they are unreferenced - see Wikidata:Living people. Contact an administrator if a user is systematically causing harm. ArthurPSmith (talk) 17:09, 22 March 2019 (UTC)

Merge artistic creation (Q47407603) and artistic creation (Q29586009)?[edit]

I wonder whether artistic creation (Q47407603) and artistic creation (Q29586009) should be merged. - The former refers to the "process during which a work of art comes into being", while the latter is defined as "economic activity involving the creation of artistic works". Any thoughts? --Beat Estermann (talk) 07:54, 11 March 2019 (UTC)

@Valentina.Anitnelav, Andrawaag: who created these artistic items. Multichill (talk) 16:57, 11 March 2019 (UTC)
I'm not sure if I fully understand the scope of artistic creation (Q29586009), but according to the description and a catalog code (P528) for the Statistical Classification of Economic Activities in the European Community (Q732298) artistic creation (Q29586009) represents artistic creation as an economic activity, which is not the case with artistic creation (Q47407603) which also includes notions of artistic creation outside the economical system (e.g. as a self-sufficient activity). I think it is safe to say that artistic creation (Q29586009) is a subclass of artistic creation (Q47407603). - Valentina.Anitnelav (talk)
That is a good question. Although related I would argue that both terms are distinct enough from each other to stay separate, as much as Apple can be refering to a fruit or a computer. artistic creation (Q29586009) is a term from a vocabulary of economic activities use to meassure economic activity with a country. --Andrawaag (talk) 21:57, 11 March 2019 (UTC)
@Valentina.Anitnelav, Andrawaag: Ok, I've followed Valentina's argument and have defined artistic creation (Q29586009) as subclass of artistic creation (Q47407603) (and of "economic activity"). Cheers, --Beat Estermann (talk) 14:04, 18 March 2019 (UTC)

Popular classifieds website Friday-Ad[edit]

I'm looking to add the Friday-Ad to wikidata. It's a very large UK classifieds and commununity website, popular down in the south of England. It's a leading marketplace for motors, pets and all sorts of second hand goods. You can view it here: https://www.friday-ad.co.uk/

Its similar to Gumtree (https://www.wikidata.org/wiki/Q5618258) and Preloved https://www.wikidata.org/wiki/Q17014403  – The preceding unsigned comment was added by Miloatfriday (talk • contribs) at 2019-03-12 14:13 (UTC).

Best place to discuss schema?[edit]

I have some potentially-elaborate questions concerning the way we represent things such as:

  • time zones, especially "this entity is in this time zone during part of the year (and this other one during another)"
  • qualified geographic coordinates, such as "coordinates of geographic center" and "coordinates of river mouth"

(But don't answer these yet; I already know the easy answers.)

Is this the right place to discuss things like those, or is there some other forum dedicated to the schema? (And when I say "schema", do I really mean "ontology"?) Scs (talk) 03:26, 13 March 2019 (UTC)

Traditionally, discussions happen on the talk pages for particular properties. I don't think this tradition is that great, from the point of view of sustained documentation, and building on the data modelling work that goes on. You can start a discussion in that way, and ping people who you think would be interested. Or you can just use user talk pages. Or you can try a general forum, or a WikiProject talk. To move things on, you may need a few attempts. Charles Matthews (talk) 11:39, 13 March 2019 (UTC)
We got WikiProject Ontology and Help:modeling was an attempt to centralize or give an entry points to all such discussions. author  TomT0m / talk page 11:50, 13 March 2019 (UTC)
Eventually there should be a consensus that a detailed "manual of style" is really needed. Right now people tend to adopt what they see as good practice on items. That's the wiki way, emergence of norms because they make sense. I'm more interested in biography than geography, but these are areas with millions of items. I think the community here should move ahead from single properties and try to develop a manual. This and referencing are the fundamental issues on content. Charles Matthews (talk) 16:59, 13 March 2019 (UTC)
@Scs, Charles Matthews, TomT0m: Note Wikidata:WikiProject ShEx is working on implementing a type of schema definition language within Wikidata - this project is in testing now, and you probably should try it out and give the developers some feedback! ArthurPSmith (talk) 17:21, 14 March 2019 (UTC)
Mmmm, I rather imagined that "shape expressions" were there to extend constraints for properties. Perhaps I misjudged them. Charles Matthews (talk) 17:57, 14 March 2019 (UTC)
I think we have attempted to use property constraints to define reasonable schemas in the past, but this is a more direct approach. ArthurPSmith (talk) 14:24, 15 March 2019 (UTC)
In the past I have repeatedly asked to explain the reasons behind a schema that is largely opaque. I have often questioned all kinds of arbitrariness and the only result has been silence. Making for stronger restrictions is not acceptable because it means that you insist to move away from the Wiki way.
As long as there is no time taken to explain what in my views is hardly any relevance. I am flat against any increased restrictions. Thanks, GerardM (talk) 16:39, 16 March 2019 (UTC)
Thanks for all those answers. I appreciate what Charles Matthews said about "emergence of norms because they make sense"; I guess I didn't realize wikidata was still that fluid.
For the sake of the discussion, I'll flesh out my (now three) hypothetical questions slightly:
  1. Some entities (e.g. Cambridge (Q49111)) are located in time zone (P421) with a numeric value such as UTC−05:00 (Q5390) (or often two, qualified by valid in period (P1264) standard time (Q1777301) or daylight saving time (Q36669)). Some entities (e.g. Boston (Q100)) link to named timezones like Eastern Time Zone (Q941023). Some entities link to entities for IANA timezones like America/New_York (Q28146035). Some entities (e.g. Italy (Q38)) do more than one of the above. What's the right way?
  2. Some entities use property coordinate location (P625) to associate more than one geographical coordinate. For example, rivers (e.g. Charles River (Q794927)) often have two, qualified by applies to part (P518) river source (Q7376362) and river mouth (Q1233637). But on the other hand, there's property coordinates of geographic center (P5140). Why does it exist? Why not use plain P625 with a qualification, just like river sources and mouths?
  3. Many cities are instance of (P31) city (Q515). But many others are instances of narrower classes, like city of the United States (Q1093829). (And of course city of the United States (Q1093829) is a subclass of (P279) city (Q515).) But should all cities explicitly be plain city (Q515)s (to make it easier for people writing queries for things like "all cities with population greater than 123456")? Or do people writing queries always have to worry about subclasses?
These are the sort of questions that (a) I'd hope one day anyone could answer by reading a nice document describing the wikidata schema, or if not (b) I was wondering where one ought to ask about them. (For now I guess I'll ask them here, albeit in new threads below.) Scs (talk) 17:10, 16 March 2019 (UTC)
On the last one: despite the similarity of names, city (Q515) and city of the United States (Q1093829) are quite different sorts of things. Q515 means a larger urban agglomeration, the usual meaning of "city". Q1093829 means an entity in the U.S. that is officially a "city", which is a form of administrative unit in the U.S. (which differs a bit from state to state). Some of these Q1093829 "cities" are quite small, even populations under 1000, so the are by no means Q515 cities. Conversely, to stick to a U.S. example, city of the United States (Q1093829) has a population of 43,713 but is a village of New York (Q55237813), a New-York-State-specific designation for a different form of administrative unit, even though it dwarfs many Q1093829 cities. - Jmabel (talk) 03:04, 17 March 2019 (UTC)
@Jmabel: Thanks for the reminder that terms like "city" mean different things to different people. That wasn't really my question, though -- my question would have remaind the same if I'd been asking about finding instances of, say, human settlement (Q486972). And I've since learned that the answer is basically "Yes, Wikidata type-class entities are typically deeply nested, but that's okay, because everyone knows to write their ordinary is-a queries using wdt:P31/wdt:P279*." Scs (talk) 14:57, 22 March 2019 (UTC)
@Scs: On time zones - all the items you list are instances of (instance of (P31)) time zone (Q12143) either directly or indirectly (via time zone named for a UTC offset (Q17272482) which is a subclass (subclass of (P279)) of time zone (Q12143). The values allowed for a property like located in time zone (P421) are specified in its property constraints - you will notice there is a "value type constraint" that specifies the values must be instances of time zone (Q12143). This is common across Wikidata properties - to the extent we can, we attempt to document the way properties should be used via their constraints. Similarly, the shape expressions I mentioned would be a way to improve documentation of items (within a specific class of items) to show what properties they should have, etc. ArthurPSmith (talk) 14:15, 18 March 2019 (UTC)
@ArthurPSmith: Thanks, although that much, at least, I'd figured out already. See link to further discussion just below. Scs (talk) 14:57, 22 March 2019 (UTC)
Thanks again for the various replies. For now, the only big new thread I'm starting on any of this is on time zones, at Property talk:P421. Scs (talk) 14:57, 22 March 2019 (UTC)

Automated processes and references[edit]

Here’s a question that may lead to an RfC, depending on your responses:

At this stage of Wikidata's evolution, should automated processes/bot jobs that add statements without also adding references for those statements be strongly discouraged?

I would assume there would be exceptions for statements like <instance of>, <subclass of>, and external identifiers, and for self-referencing items like books. Thoughts? - PKM (talk) 20:31, 14 March 2019 (UTC)

Different areas of Wikidata are more developed than others, and different areas are more in need of references than others, or more in need of raw quantity than others. There are many areas in which bots adding unreferenced statements would be less than welcome, and others where bot-added unreferenced (but hopefully at least minimally curated) statements would be a useful addition. --Yair rand (talk) 20:45, 14 March 2019 (UTC)
I do not think we should require references for automated editing, for several reasons:
  • You mention that there will be exceptions, but who defines which ones would be acceptable? I think there will be lots of exceptions and also exceptions from exceptions, which could make it difficult to comply with such a complicated policy.
  • Mandatory references complicate the batch/bot editing process, so new and less tech-savvy users might find it difficult to contribute to Wikidata.
  • There are plenty of worthless references available already now, often from batch jobs where users wanted to do it correctly, but their references are either not well-shaped, or the sources do not support the actual statement. I’d expect reference quality to decay a lot once we made their addition mandatory.
MisterSynergy (talk) 20:50, 14 March 2019 (UTC)
Which particular bots do you think should be discouraged? ChristianKl❫ 14:07, 15 March 2019 (UTC)
I've looked at item maturity in the past. A proto-item is for example a new empty item just created with one sitelink to Wikipedia. On the other end of the scale we have items that are very extensive and very well sourced. For proto-items I'm quite happy to just get some statements on them, with or without references.
These days most automated tools and bots add references, right? Do you have some examples without references? I'm especially interested in items that don't link to Wikipedia. Multichill (talk) 14:42, 15 March 2019 (UTC)
Sometimes applying Help:Edit summary (Q4533519) is enough. --Succu (talk) 21:54, 15 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Thanks, all, for the comments. Clearly further action is inappropriate at this time. - PKM (talk) 19:52, 17 March 2019 (UTC)

Indicating verified accounts[edit]

There seem to be two approaches for indicating "verified" accounts on social media - has quality (P1552):verified account (Q28378282) 110 times, or has quality (P1552):verified badge (Q48799541) (example query for twitter)

Overall, a reasonably even split between calling it an "account" or a "badge". I don't have any strong feelings on which one we use, but it feels like we ought to be consistent and pick one. Any thoughts as to which is more appropriate? They have quite different class hierarchies but seem to be tied together by has effect (P1542) and has cause (P828). Andrew Gray (talk) 23:30, 15 March 2019 (UTC)

verified account (Q28378282) seems like the right one to me, since that would be an account quality, while verified badge (Q48799541) would be a badge quality. Ghouston (talk) 00:39, 16 March 2019 (UTC)
I agree that verified account (Q28378282) reads like a better target for has quality (P1552), though verified badge (Q48799541) does seem like it's a more precise item to use, and might have been the more obvious choice with a slightly different qualifier property. It's probably also worth noting that instance of (P31) seems to be used even more as a qualifier for this purpose (>300 times on Twitter username (P2002), all with verified account (Q28378282)), so if we're going to run a bulk migration to tidy these up, it might be worth looking at fixing those too. --Oravrattas (talk) 07:34, 16 March 2019 (UTC)
Oh, well spotted - I didn't think to look for non-standard qualifiers. Instagram username (P2003) (which allows P31 in its constraints) has 59 "verified account"; Instagram username (P2003) has 131; YouTube channel ID (P2397) has seven (plus a couple of values for other things). So those are consistent, at least, even if possibly on the wrong qualifier. Andrew Gray (talk) 11:42, 16 March 2019 (UTC)
Great initiative! One observation: not all verified accounts have verified badges, but all verified badges belong to verified accounts. Facebook specifically operates with different colored badges to reflect this, Youtube has verified music accounts with or without badges, there are probably more examples. Moebeus (talk) 12:11, 16 March 2019 (UTC)
I'm thinking it would be a good idea to rename en:Verified badge to Verified account, for this reason. It has already gone wrong with "In February 2012, Facebook introduced verification badges for profiles and pages", trying to describe all such systems as "badges". Ghouston (talk) 22:05, 16 March 2019 (UTC)
But that name redirects to en:Account verification. Amazingly, the Verified badge article doesn't mention the former. Perhaps these two articles should be proposed for merging. Ghouston (talk) 22:02, 17 March 2019 (UTC)

Rank for fictitious authors listed alongside actual authors of a paper[edit]

At The Morphology of Steve (Q50422077), there is some disagreement whether only the 3 actual authors should have normal or preferred rank in author (P50) and the others deprecated rank.

The reference for this was added https://www.wikidata.org/w/index.php?title=Q50422077&diff=859685070&oldid=859683269 but deleted by some user. --- Jura 09:42, 16 March 2019 (UTC)

Aubrey
Viswaprabha (talk)
Micru
Tpt
EugeneZelenko
User:Jarekt
Maximilianklein (talk)
Don-kun
VIGNERON (talk)
Jane023 (talk) 08:21, 30 May 2013 (UTC)
Alexander Doria (talk)
Ruud 23:15, 24 June 2013 (UTC)
Kolja21
arashtitan
Jayanta Nath
Yann (talk)
John Vandenberg (talk) 09:14, 30 November 2013 (UTC)
JakobVoss
Danmichaelo (talk) 19:30, 16 February 2014 (UTC)
Ravi (talk)
Mvolz (talk) 08:21, 20 July 2014 (UTC)
Hsarrazin (talk) 07:56, 9 August 2014 (UTC)
Accurimbono
Mushroom
PKM (talk) 19:58, 10 October 2014 (UTC)
Revi 16:54, 29 November 2014 (UTC)
Giftzwerg 88 (talk) 23:36, 1 January 2015 (UTC)
Almondega (talk) 00:17, 5 August 2015 (UTC)
maxlath
Jura to help sort out issues with other projects
Epìdosis
Skim (talk) 13:52, 24 June 2016 (UTC)
Marchitelli (talk) 12:29, 5 August 2016 (UTC)
BrillLyle (talk) 15:33, 26 August 2016 (UTC)
Alexmar983 (talk) 23:53, 28 August 2016 (UTC)
Finn Årup Nielsen (fnielsen) (talk) 10:44, 29 August 2016 (UTC)
Chiara (talk) 14:15, 29 August 2016 (UTC)
Thibaut120094 (talk) 20:31, 14 September 2016 (UTC)
Ivanhercaz | Discusión Plume pen w.png 15:30, 31 October 2016 (UTC)
YULdigitalpreservation (talk) 17:35, 10 November 2016 (UTC)
User:Jc3s5h
PatHadley (talk) 21:51, 15 December 2016 (UTC)
Erica (ohmyerica) (talk) 19:26, 1 January 2017 (UTC)
User:Timmy_Finnegan
Mauricio V. Genta (talk) 05:38, 12 March 2017 (UTC)
Sam Wilson 09:24, 24 May 2017 (UTC)
Sic19 (talk) 22:25, 12 July 2017 (UTC)
Andreasmperu
MartinPoulter (talk) 09:21, 20 July 2017 (UTC)
ThelmadatterThelmadatter (talk) 01:11, 13 September 2017 (UTC)
Zeroth (talk) 15:01, 16 September 2017 (UTC)
Emeritus
Ankry
Beat Estermann (talk) 20:07, 12 November 2017 (UTC)
Shilonite - specialize in cataloging Jewish & Hebrew books
Elena moz
Oa01 (talk) 10:52, 3 February 2018 (UTC)
Maria zaos (talk) 11:39, 25 March 2018 (UTC)
Wikidelo (talk) 13:07, 15 April 2018 (UTC)
Mfchris84 (talk) 10:08, 27 April 2018 (UTC)
Mlemusrojas (talk) 3:36, 30 April 2018 (UTC)
salgo60 Salgo60 (talk) 12:42, 8 May 2018 (UTC)
Dick Bos (talk) 14:35, 16 May 2018 (UTC)
Marco Chemello (BEIC) (talk) 07:26, 30 May 2018 (UTC)
Harshrathod50
 徵國單  (討論 🀄) (方孔錢 💴) 14:35, 20 July 2018 (UTC)
Alicia Fagerving (WMSE)
Louize5 (talk) 20:05, 11 September 2018 (UTC)
Viztor (talk) 05:48, 6 November 2018 (UTC)
RaymondYee (talk) 21:12, 29 November 2018 (UTC)
Merrilee (talk) 22:14, 29 November 2018 (UTC)
Kcoyle (talk) 22:17, 29 November 2018 (UTC)
JohnMarkOckerbloom (talk) 22:58, 29 November 2018 (UTC)
Tris T7 TT me
Helmoony (talk) 19:49, 8 December 2018 (UTC)
Naunc1
Shooke (talk) 19:17, 12 January 2019 (UTC)
DarwIn (talk) 14:58, 14 January 2019 (UTC)
I am Davidzdh. 16:08, 18 February 2019 (UTC)
Juandev (talk) 10:03, 27 February 2019 (UTC)
Pictogram voting comment.svg Notified participants of WikiProject Books pinging project --- Jura 09:45, 16 March 2019 (UTC)

Why have you repeatedly marked the named, cited, editors as deprecated? some user; Talk to some user 14:52, 16 March 2019 (UTC)
This sounds like a technicality in how "author" is defined: the names listed on the article, or the people who actually wrote it? They will almost always be the same, or at least assumed to be the same for lack of other evidence. Ghouston (talk) 22:08, 16 March 2019 (UTC)
I suppose a relatively common situation would be ghostwriter (Q623386) or some kind of fraud in publishing somebody else's text. Ghouston (talk) 22:16, 16 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── If the named authors were not consulted, then qualifiyng with a "has role"-"unconsulted author" may be appropriate; deprecation - and especially deprecation with no reason as a qualifier - is not. This has nothing to do with ghostwriting. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:43, 17 March 2019 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

  • To return to the original question, what do others think? --- Jura 20:09, 17 March 2019 (UTC)
I think we agree that an author can be added, even if not stated on the publication, if there's a reliable reference that says they were an author. So it's consistent to also say that authors can be removed if there's a reliable reference that says they didn't contribute to it in any way, at least in cases like this where's there's no dispute. If you were generating a list of works for one of those fake authors, it doesn't seem right to include this article. Ghouston (talk) 23:05, 17 March 2019 (UTC)
No, that's not consistent; not what was proposed (the issue was around improper deprecation, not removal); and not something we agree on. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:21, 18 March 2019 (UTC)
  • I think Ghouston's point is supported by Help:Ranking. --- Jura 20:04, 18 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── There is nothing on Help:Ranking that supports removing such data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:34, 18 March 2019 (UTC)

Where I said removal, I'd support deprecation as a better alternative, and maybe a new reason for deprecation. Ghouston (talk) 22:32, 18 March 2019 (UTC)

Importing UIDs for people, from Wikispecies[edit]

The page I have just at species:Wikispecies:Biographies with no identifiers contains a Wikidata query which returns a list of people with a Wikispecies biography, but with no UIDs (VIAF, ISNI, ORCID, IPNI, Zoobank, etc) on Wikidata.

There are currently 20,183 people in the list! Some of them, such as species:A. Murdoch, have an ID (Zoobank, in this case) as part of links in the Wikispecies article text. These are often not templated (as in Murdoch's page), or use a template which is ambiguously used for both people and works, such as species:Template:ZooBank, where we have two or more ID properties (e.g. ZooBank author ID (P2006)/ZooBank publication ID (P2007), so the HarvestTemplates tool cannot be used).

Can anyone help with automating the importing of such values? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:50, 16 March 2019 (UTC)

You can harvest in demo mode, download the data and then process it further using other tools such as PetScan and PagePile. Thierry Caro (talk) 20:28, 16 March 2019 (UTC)
Thank you. That's useful tip, but turns out to have a very small return. It seems the vast majority of such IDs are not in templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:48, 16 March 2019 (UTC)
Can anyone assist? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 22 March 2019 (UTC)

Scientific names of taxa should be a separate entities from the taxa themselves[edit]

Currently, a scientific Latin name for an organism is a property of a taxon, rather than an entity in of itself. However, this causes inconsistencies. Each Latin name has one or more authors, an associated protolog, a publication and a type specimen in a collection. These pieces of information are only related to the Latin name and not the taxon. The taxon is a scientific concept and the earliest valid name is chosen as a label for this concept. This problem with the data model means that the International Plant Names Index (Q922063) identifiers are being used as properties of taxa, which they are not. They are identifiers for published Latin names (valid or not). This is causing me problems because I want to link nomenclatural type specimen details with the name that they are types of, but I can only link them to taxa.

How do we go about getting this change?

Is there a will to fix this?

How do we represent type specimens in Wikidata and their links to names?

I imagine it will be painful, but it is better to do this sooner rather than later Qgroom (talk) 09:20, 17 March 2019 (UTC)

  • I agree with the general problem and think it would be desireable to the taxons in the Q-namespace and the names in the L-namespace, where names belong. ChristianKl❫ 20:57, 17 March 2019 (UTC)
At this stage, this involve splitting hundreds of thousands of items from each others. As much as I like the idea myself, I don't think it's realistically feasible whatsoever (not to mention how the distinction is completely lost of most people who are not deeply familiar with codes of nomenclature for organisms). Circeus (talk) 11:29, 17 March 2019 (UTC)
It might be hard, but if the data model is demonstratably wrong isn't the situation only going to get worse the longer it is left? It may be hundreds of thousands of items now, but it will be millions of items eventually. The problem will mean that Wikidata will fail to be useful for biodiversity informatics, where it could be a real game changer. Wikidata's unique selling point it that it can be fixed. Qgroom (talk) 12:15, 17 March 2019 (UTC)
@Qgroom: Some thoughts from 2016. --Succu (talk) 13:06, 17 March 2019 (UTC)
  • My outside impression is that we had someone complain the other day about Wikidata doing the opposite? --- Jura 11:51, 17 March 2019 (UTC)
The opposite of what? Qgroom (talk) 12:16, 17 March 2019 (UTC)
  • The opposite of what you are complaining about by creating new items for every name. --- Jura 12:20, 17 March 2019 (UTC)
I suppose Wikidata could get so big that it just grinds to a halt, but there are an estimated 9 million species. Not all of these are described, but even if they were and each one had two names then it is not going to be a number that Wikidata can't handle. Apparently, there are 2.5 million scientific publications published every year and these are getting added to Wikidata Qgroom (talk) 12:33, 17 March 2019 (UTC)
  • I think it's already being done. If homo sapiens is or was also called something else, there would be a separate item for that name. We just generally don't have an item like Q5. --- Jura 12:45, 17 March 2019 (UTC)
Although Q5 has the description "common name of Homo sapiens..." it is clear from its properties that it is refering to much more than the name. I suspect Q5 and Q15978631 should be merged, because they both describe the concept of humanness and neither describes the name, whether Latin or English.  – The preceding unsigned comment was added by Qgroom (talk • contribs) at 12:58, 17 March 2019‎ (UTC).

────────────────────────────────────────────────────────────────────────────────────────────────────

Wikidata asserts that this is a picture of a common name

This is certainly a serious concern, which is stopping the use of Wikidata in other WMF projects, and externally. It's also internally incongruent - we don't define table (Q14748) as "name of a piece of furniture". One of the many prior discussions is "What heart rate does your name have?". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:59, 17 March 2019 (UTC)

Thanks @Succu: and @Pigsonthewing: for those links to earlier discussions on the topic. I had imagined the subject was going to be difficult, I was not wrong.  – The preceding unsigned comment was added by Qgroom (talk • contribs) at 14:12, 17 March 2019‎ (UTC).
@Pigsonthewing: No, please don't merge human (Q5) and Homo sapiens (Q15978631), they reflect closely related, but distinct concepts. When we started out with reflecting human genes on Wikidata, we used the statement found in taxon (P703) human (Q5), however, this lead to inconsistencies, basically because of human (Q5) not being a taxon (Q16521) and as such didn't fit with genetic models. You could argue that by simply making human (Q5) instance of (P31) taxon (Q16521) fixes this, however there are examples (e.g. Lexa (Q23023325) where an item is righteously instance of (P31) human (Q5), but not instance of (P31) Homo sapiens (Q15978631). --Andrawaag (talk) 10:13, 18 March 2019 (UTC)
Don't worry I've no intention of messing with humans. The point is, humans are exceptional in a number of ways and in this case we should not get deflected by these special cases.Qgroom (talk) 11:49, 18 March 2019 (UTC)
@Andrawaag: Where did I propose such a merge? I've fixed Q23023325, which should not have been using Q5. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:09, 18 March 2019 (UTC)
@Pigsonthewing: You were the first signature after "I suspect Q5 and Q15978631 should be merged". It seems that I was wrong there, appologies. --Andrawaag (talk) 22:23, 18 March 2019 (UTC)
I'm hardly a WikiData expert, but about all i do on here relates to taxa. Here are some thoughts:
  1. Many common names relate to more than one taxon, so if this separation happens, it needs to accommodate many q-items using the same common name item.
  2. Many taxa already have more than one scientific name, mainly in the form of synonyms. I am under the impression that each synonym should have it's own separate q-code. Even if this is not the desired policy, it is certainly happening in many cases. In these cases, it approaches the situation requested above. I think if we want one item for a common name and scientific name, we'd have to combine more than one scientific name. Personally, with how names change back and forth this may be unwise.--NessieVL (talk) 01:41, 19 March 2019 (UTC)

Here are some thoughts...[edit]

Use cases[edit]
  • Finding where type specimens are
  • Testing that there is only one holotype, lectotype or neotype.
  • Testing other rules of nomenclature
  • Testing that the authorship of names is correct
  • Finding the literature on the naming of taxa
  • Linking names of taxa to authors
  • Testing that the name has been legitimately typified
  • Identifying syntype material
Ways forward?[edit]
  • Ignore the cases of cats, dogs and humans and start with the more obscure and therefore less controversial taxa.
  • Continue labelling taxon concepts as they are now as Instance of P31 Taxon Q16521 with a label, such as "Viola lutea"
  • Add new scientific name items as Instance of P31 name Q82799 (or preferably a new item class - scientific Latin name)
  • Label these new scientific name items with something like "Viola lutea Huds. (name)"

Doubtless I'm being too naive, but if there are ways to breakdown a difficult problem into manageable chunks then perhaps it is solvable.  – The preceding unsigned comment was added by Qgroom (talk • contribs) at 14:12, 17 March 2019‎ (UTC).

PS: One thing I note is that previous discussions have conflated taxonomy and nomenclature. The later is concreate, has tightly defined rules and is therefore much more tractable in a database than taxonomy, that often comes down to a matter of opinion.  – The preceding unsigned comment was added by Qgroom (talk • contribs).

  • I think we should get inspired from Darwin Core, with their occurence system that allow to store, and then retrieve, the infos about specific specimens into databases. If we allow that a specific specimen, or group of specimens, can have an item, then it will be easy to store a lot of infos including something like subject has role (P2868) holotype (Q1061403) of (P642) of the taxon of your choice.
    Furthermore in the perspective of the future that binds more and more Wikimedia Commons and Wikidata, it will be great if one day we can import with automated tools the images of free datasets into Wikimedia Commons and the and related information into Wikidata, example see this occurence and this image manually uploaded into Commons and where related information is currently poorly rendered and used (+the work is too important to be done manually in the long run). I dream that one day the free datasets of gbif be imported into the Wikimedia Project (medias in Commons and infos in Wikidata). Christian Ferrer (talk) 21:30, 17 March 2019 (UTC)
Yes, but one specimen can be the nomenclatural type of multiple names and be cited in several publications. So it doesn't get around that the name is an entity in of itself. All the nodes of the biodiversity knowledge graph are individual entities (http://bionames.org/~rpage/towards-knowledge-graph/).
If you have an issue with the current system, then with the name as an entity, you move this issue to this new entity, but you solve nothing. Christian Ferrer (talk) 12:15, 18 March 2019 (UTC)
Example, here Dermechinus horridus (Q2743032) and the synonym (also the original combination) Echinus horridus (Q62085775). If you have two different name, and that you need the both names here for a strucutred data purpose, then create a new item, as I show in my example. Or as much as you need. Christian Ferrer (talk) 12:25, 18 March 2019 (UTC)
Two properties pointing to the name[edit]

I am wondering if the convention used in Wikicite wrt to author names in using both author (P50) and author name string (P2093) can apply here as well. The ideal solution would be to change taxon name (P225) to accept items instead of string, but given that taxon name (P225) is already in widespread use changing seems impossible. Hence mimicing the wikicite solution with authors helps? Just my 2cts. --Andrawaag (talk) 22:06, 17 March 2019 (UTC)

Yes, I think that taking inspiration from the item/ string split between author (P50) and author name string (P2093) looks promising. In that vein, I think the current taxon name (P225) should remain as a string property, and the only thing we would have to change there would be the labels of P225, to "taxon name string" (and equivalents in other languages). This would then be complemented by a new property "taxon name" (or perhaps better "taxon name item", to reduce the ensuing confusion) that would point to an item. Once we have a P50 statement on a publication item, we usually remove the P2093 one (storing its value via stated as (P1932)). I think the "taxon name string" statement would eventually have to be deleted from the taxon item (and migrated to the taxon name item), but perhaps we should allow for some more time here than for the P50-to-P2093 conversion. --Daniel Mietchen (talk) 03:23, 18 March 2019 (UTC)
No. That will not work. Properly done, a taxon has four parts; the name (ie taxon), the author (ie possibly multiple names), the publication and the date. This is what it takes to uniquely describe a taxon. I have said it before and I say it again. Thanks, GerardM (talk) 06:23, 18 March 2019 (UTC)
I am not sure I understand. Isn't the issue here that there is a need to distinguish between a taxon and a taxon name. You argue that a taxon is described by 4 concepts of which its name is one. But you also argue that the name is the taxon, which at the same time is one of the four characteristics of a taxon. Isn't this the kind of Droste effect being addressed here? --Andrawaag (talk) 09:36, 18 March 2019 (UTC)
I think the anology with author (P50) and author name string (P2093) is a good solution that is non-disruptive, but allows progress. How do we get this done? Qgroom (talk) 11:57, 18 March 2019 (UTC)
  • There is no need to separate the taxon from the taxon name, an item about a taxon is and should stay an association of different things (name, author, date). In case of synonymy, then this is not anymore the same association and a new item is needed and have to be "instance of/ synonym of..". In the extend, of course, that we think relevant to have this item here, example in case of original combination, but we don't need to list all synonyms IMO, though the debate can stay open. But in all case when a species is "renamed" and that the a new name is accepted, we must absolutely create a new item, not change what is written in the string field "taxon name", as it is sometimes the case here. To come back about a potential separation of the taxon name, this will solve nothing of any potential issue (if any), it will just complicate things. A taxon is absolutly not "a thing with potential different names", because when the names are different then we talk about different taxa. A taxon without "taxon name" is not a taxon. We are not going to reinvent science. Christian Ferrer (talk) 12:12, 18 March 2019 (UTC)
@Christian Ferrer: "A taxon without 'taxon name' is not a taxon" – the ICZN in the glossary entry for "taxon" says it's a taxonomic unit whether named or not, so you are using a different definition to the Code. Peter coxhead (talk) 17:27, 19 March 2019 (UTC)
@Peter coxhead: There is no need to push the ontology so far. As a data, yes of course yes, a taxon is not a taxon without a name and without the resulting properties of that taxon name. Christian Ferrer (talk) 17:59, 19 March 2019 (UTC)
There is a need. As said before, a taxonomic name is linked to a type specimen, an author and a protologue and these are not properties of the taxon, they are properties of the name. The taxon, is a biological hypothesis and is much more fluid in its scope. There is no single authority for which name is accepted. What is accepted is always a matter of opinion. On the other hand taxonomic names are concreate, founded on clear rules. Taxonomic synonyms are not just different names for the same thing. A name can even exist even if we don't know what taxon it is supposed to represent. These names are an important link between the biology, collections and scientific literature. Qgroom (talk) 14:21, 18 March 2019 (UTC)
Each taxa item here has currently only one taxon name, almost all if not all the other properties (included, and in addition of what you quote yourself, the parent taxon, and all external identifiers) are relative to that specific name, you said it very well, and if you move the name then you need to move all the rest, therefore you move nothing. The only thing that can stay, and not for all cases, is the common name. Christian Ferrer (talk) 17:46, 18 March 2019 (UTC)
@Christian Ferrer: each item incorrectly claimed to be an instance of a taxon has only one taxon name, because it is actually an instance of a taxon name, not a taxon. See #Previous discussion below. Many taxa are represented here by multiple taxon names. Peter coxhead (talk) 17:02, 19 March 2019 (UTC)
@Peter coxhead: Yes and no. What would be an instance of taxon otherwise? what will be the label? it is just a concept that take consistency only when it is named and defined. And as I noted above, absolutly all the other properties currently used are depending of that name and definintion, therefore if you have an item for the taxon name, you have in this item all the other properties too (external identifiers, rank, parent taxon, publications, author, sitelinks, ect...). What will be in this item "taxon" in addition of a property taxon name where the value will be the Qitem of the taxon name? absolutly nothing because everything flows from this taxon name and from all the properties that are unique to that taxon name. The only thing that it will allow to do it is the possibility to add multiple values to that property taxon name, but ultimately it does not bring nothing because currently you can create synonym items as much as you need. Therefore to change completely will create a lot of issues to solve none. Christian Ferrer (talk) 17:50, 19 March 2019 (UTC)
Assuming that we were changing "instance of taxon" to "instance of taxon name", not a single property of Holothuria scabra (Q2395506) will be changed. And what? The only result will be a potential (big) disrupion of the Wikimedia projects that are currently using tools that works with "instance of taxon", but what's new? What is the interest to materialize the "true" concept of "taxon" in a structured data? what will be the name of that item "taxon", what label? the accepted name, maybe? but this is the current situation, ....no?!? the other names are synonyms, thing that they can currently be, so what new? Christian Ferrer (talk) 19:00, 19 March 2019 (UTC)
In my opinion Wikicite is a disaster creating wrong titles, duplicated items etc. example often making it hard to add basionym (P566) or original combination (P1403) based on sources. --Succu (talk) 21:28, 18 March 2019 (UTC)

Possible solution[edit]

With our existing infrastructure we can use lexemes for the latin names and use item for this sense (P5137) to link them to our taxon items, the new lexeme/sense items can get the information about taxon author and publication. A bot could simply do this for all the existing taxons that we have. As a next step we can merge items that describe the same taxon via the existing information from taxon synonym (P1420). Does anybody see problems with doing that? ChristianKl❫ 12:09, 18 March 2019 (UTC)

Though this solution is at the opposite of the original subject, that tend to divide than to merge. For a structured purpose, e.g. if we need to link a specimen as to be a specific type, example "holotype", of a specific taxon with a specific name (even if is not the current accepted name) then we need an item for this specific taxon. And this is currently possible with the current system, see my example. You can very well have a specimen that is the holotype of Echinus horridus (Q62085775), while the accepted taxon is Dermechinus horridus (Q2743032). For that purpose of what is needed is that we allow to create items for specific zoological specimen (Q2114846) or something similar. No really, no, in taxonomy, the same thing with two different name is not the same thing but well two different things, we need to keep the item separate. Christian Ferrer (talk) 12:55, 18 March 2019 (UTC)
Yes, I agree Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) should be merged, because they refer to exactly the same species concept. However, these items have conflated name information and taxon information. So that the properties taxon author citation (P6507) and publication in which this taxon name was established (P5326) would then need cleaning up. If names were separated from the species concept then multiple species concepts could coexist, as they already do in the real world. Qgroom (talk) 14:35, 18 March 2019 (UTC)
I fail to understand why we should clean up the original publication of the original name, this is useful information. As well as the author citations of both items are useful, as these both citations are (different) currently used, example. Further more a taxon name is linked to one specific author citation, therefore if you quote the name somewhere you have to quote the author citation too. Christian Ferrer (talk) 18:13, 18 March 2019 (UTC)
@Christian Ferrer:Why do you consider that to be important. Why isn't it enough when we store the orginal name in the source document with some form of 'states as'? ChristianKl❫ 15:48, 18 March 2019 (UTC)
@ChristianKl: Here the taxa items currently need a rank, a name and a parent. A taxon synonym have obvioulsy a different name, may have a different rank (e.g. a species can be a synonym of a subspecies), and may have a parent taxon different (in the facts all is (or may be) different, as pointed there). I fail to understand what is the interest to merge such things, in addition of that I fail to understand how can work well a taxon chain like that. Though this is not because I don't understand it that it is impossible. Christian Ferrer (talk) 17:58, 18 March 2019 (UTC)
I've listed a few of the use-cases above. These can't be resolved by treating taxonomic names and taxa as the same thing, nor by treating names as mere labels. The inconsistencies are already apparent in the Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) example. Qgroom (talk) 17:40, 18 March 2019 (UTC)

@ChristianKl: I'm a Wikidata beginner. Could you point me to some material to explain your lexeme proposal? Qgroom (talk) 14:40, 18 March 2019 (UTC)

Lexeme's are entities that represent how a given concept is called in a given language. The were recently introduced to map to Wikidictionary entities. https://www.wikidata.org/wiki/Wikidata:Lexicographical_data/Documentation provides more information. ChristianKl❫ 15:48, 18 March 2019 (UTC)
I doubt binomen (Q864016) should be treated as lexemes. --Succu (talk) 20:46, 18 March 2019 (UTC)
Claiming that Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) refer to "the same species concept" is a huge stretch. In almost all cases it is impossible to say to what species concept a name refers to without citing at least one actual taxonomic paper. There are very few Wikidata items that refer to a particular species concept; this is only possible if the taxon is very well-known and uncontroversial or if an item is defined in terms of a particular taxonomic position.
        The basic issue is that scientific names can be databased very easily, and one name per item allows adding all nomenclatural information, such as authorship of the name, and any detail on typification (in principle, we may need extra properties).
        On the other hand taxa can not be databased at all (with a few exceptions) except by using scientific names. And scientific names can refer to any number of differently defined taxa.
        Having one item for one scientific name allows any bit of data from the literature to be databased accurately. Recording information accurately surely should be the foundation of any database policy. - Brya (talk) 17:51, 19 March 2019 (UTC)
"refer to "the same species concept" is a huge stretch." yes, and this is why there is currently two different items. Christian Ferrer (talk) 18:03, 19 March 2019 (UTC)

Types[edit]

We have taxonomic type (P427) to add them. What we are missing is a data model for types at species rank and below. This are your major use cases above, Qgroom. How should we do this? --Succu (talk) 19:09, 18 March 2019 (UTC)

taxonomic type (P427) is about type species, despite the similar sounding name, this is something completely different to a type specimen. Qgroom (talk) 20:17, 18 March 2019 (UTC)
No. Please see Rausch 572 (Q19359611). --Succu (talk) 20:30, 18 March 2019 (UTC)
I don't understand. Rausch 572 (Q19359611) is a type specimen, it is not a necessarily a taxonomic type (P427) as it is defined (BTW that's a terrible label). Qgroom (talk) 21:27, 18 March 2019 (UTC)
Hopefully [1] Acanthocalycium thionanthum (Q337710) and Acanthocalycium ferrarii (Q337692) are not based on the same type. If the would be the case replaced synonym (for nom. nov.) (P694) should be applied. --Succu (talk) 21:42, 18 March 2019 (UTC)
The replaced synonym (for nom. nov.) (P694) is being used incorrectly in the item Acanthocalycium thionanthum (Q337710). The definition of replaced synonym (for nom. nov.) (P694) is "the type genus of this family (or subfamily, etc), or the type species of this genus (or subgenus, etc)". It is therefore referring to a taxon, not a specimen. So it can't be Rausch 572. This is the sort of logical inconsistency I want to resolve by making a clear distinction between taxa and taxonomic names. --Qgroom (talk) 05:51, 19 March 2019 (UTC)
I assume what is intended is taxonomic type (P427) in Acanthocalycium ferrarii (Q337692). This P427 when proposed was indeed intended for taxa, but it is not inconceivable to expand its use to include type specimens / illustrations / descriptions. However, that would mean creating an item for every type, which seems like an enormous, even a practically impossible (?) amount of work. So maybe we do need new properties. And yes, "taxonomic type" is a terrible label, but pragmatically it does need "taxon" or "taxonomic" in the name, in order not to be lost here, in this database with a huge span of coverage. - Brya (talk) 05:09, 20 March 2019 (UTC)

Sitelinks[edit]

Where to put them? Do Wikimedia project describe taxon concepts or only list names according to a special source? This includes the automatic creation of items here based on an external id. --Succu (talk) 19:38, 18 March 2019 (UTC)

Note that I don't know exactly how that works but in case of synonym in Wikimedia Commons the links may be given, example. Christian Ferrer (talk) 19:58, 18 March 2019 (UTC)
Commons prefers this taxonomic viewpoint. This includes the renaming of pictures to their preferred view point. I very bad practice. --Succu (talk) 20:17, 18 March 2019 (UTC)
Wikimedia uses taxon concepts, anything else would be odd. The case of Index Fungorum you mention is interesting. Index Fungorum is a list of names, like IPNI, however it links to Species Fungorum where a list of accepted taxa is maintained. A clear case of maintaining separation between nomenclature and taxonomy. Qgroom (talk) 20:26, 18 March 2019 (UTC)
Hard to believe Wikimedia uses taxon concept (Q38202667). Hard to believe all Wikimedia projects follow the same concept (birds, mammals, …) unisono. --Succu (talk) 20:38, 18 March 2019 (UTC)
Of what I point is not Wikimedia Commons practice but the fact that the sitelinks ca be retrieved from Rhodocybe nitellina (Q10434744) to Rhodophana nitellina (Q51954845), I guess with taxon synonym (P1420), the illustration can be seen in the Commons category that I have pointed. In summary the current system is good : no matter that a specific project use one name and another project use another name, because the current system allow the navigation in despite of that. And it is unrelative to the category redirect that you have pointed, there was a discussion about this feature on Commons, but I'm not able to find it, I know that taxon synonym (P1420) and our local infobox are involved. Christian Ferrer (talk) 21:11, 18 March 2019 (UTC)
The statement in Wikimedia Commons example is wrong. Index Fungorum make no judgement about whether Rhodocybe nitellina is an accepted name or a synonym. Index Fungorum is just a list of names. However, it does state that Rhodophana nitellina (Fr.) Papetti is the accepted name in Species Fungorum. Qgroom (talk) 21:26, 18 March 2019 (UTC)
Yes it does, though the link on Commons leads indeed to another page. But this is out of topic here, as we talk about sitelinks. Christian Ferrer (talk) 21:40, 18 March 2019 (UTC)

External IDs[edit]

Some of them are more dedicated to a nomenclatural act (eg. IPNI, IF, Mycobank, Zoobank should). A lot of them (NCBI, FishBase, IUCN …) follow a certain taxonomic viewpoint. That means the same ID can point to different scientific names. Others (e.g. WoRMS) are in between, they have Ids for accepted/valid names and earlier ones. Same question: where to put them? --Succu (talk) 20:06, 18 March 2019 (UTC)

Well that's why I'm asking for name items separate from taxon items, but perhaps the question was not directed at me. Qgroom (talk) 20:36, 18 March 2019 (UTC)
Where to put them at your proposed name centered items? --Succu (talk) 22:15, 18 March 2019 (UTC)

Previous discussion[edit]

The issue of representing taxon names versus taxa has already been discussed in great detail, more than once. See e.g. Property talk:P1420#data model.

The main points to be clear about first are:

  • A taxon is not the same as a taxon name. Explaining clearly is complicated by the different terminologies employed in the nomenclature codes, but using the ICZN here, a taxon or taxonomic unit, whether named or not, is "a population, or group of populations of organisms which are usually inferred to be phylogenetically related and which have characters in common which differentiate .. the unit .. from other such units."
  • A taxon can properly (validly, legitimately) have more than one name, if it is given a different placement within another taxon, and/or a change of rank. Thus precisely the same group of organisms may be given the name Muehlenbeckia florulenta (Q1101419) or the name Duma florulenta (Q18081078) depending on which genus a taxonomist considers them to belong to. Precisely the same group of organisms may be given the name Hyacinthaceae (Q13833438) or Scilloideae (Q133292) depending on whether the differences between them and other groups are considered sufficient to treat them as a separate family or to merge them into another family as a subfamily. There is no absolute right or wrong name in most such cases; it's a matter of legitimate taxonomic opinion.

For me, there are two issues:

  1. Wikidata should stop claiming that instances of taxon names are instances of taxa.
  2. Ideally, Wikidata should represent taxa as well as taxon names.

I have no idea why there seems to be resistance to (1).

(2) is, however, difficult, as is explained in detail at Property talk:P1420#data model. Here's another example. There are two ways of classifying the genus Hyacinthus used in the current botanical literature, as shown in the table below. 1–6 are the six taxa involved; the others are taxon names. (There's implicitly another taxon, with two possible names: for those who use the left hand column, Family Asparagaceae is a different taxon from #2, a taxon treated as a subfamily by those who use the right hand column).

1 Order Asparagales
2   Family Asparagaceae
3 Family Hyacinthaceae Subfamily Scilloideae
4 Subfamily Hyacinthoideae Tribe Hyacintheae
5 Tribe Hyacintheae Subtribe Hyacinthinae
6 Genus Hyacinthus

So

  • the same taxon (defined as the same group of organisms) has more than one name – Subfamily Hyacinthoideae in the left-hand column is the same group of organisms as Tribe Hyacintheae in the right-hand column
  • the same name applies to different taxa – to know the composition (circumscription) of "Tribe Hyacintheae", you need to know which system is being used.

As far as I am aware, no-one has yet shown in detail with a worked example how best to represent data of this kind in Wikidata. Peter coxhead (talk) 12:26, 19 March 2019 (UTC)

This mostly very good.
  • However, "A taxon can properly (validly, legitimately) have more than one name," is not a fruitful way to phrase it. A taxon can properly have only one "correct"/"valid" name (some exceptions in higher ranks) from any one particular taxonomic perspective. This is the whole purpose of the nomenclature Codes. The problem (if it is that) is that there may exist any number of taxonomic perspectives, each representing a particular scientific approach. These may be regarded as several mini-universes alternate realities, which are mutually exclusive. In each mini-universe alternate reality a taxon may have a different name, but only one name at a time. For it to have a different name, there needs to be a switch to a different mini-universe.
  • The "instance of: taxon" is a historical oddity. Basically it means nothing more than that a P225 statement is present, and "instance of: taxon name" could also have been used. However, "instance of: taxon" is not wildly inaccurate, as such things go, since any taxon name is not only a name, but is also used to refer to a taxon (that is what it is there for). Somebody, somewhere, somewhen did use it to refer to a taxon, at least once. - Brya (talk) 18:15, 19 March 2019 (UTC)
@Brya: sure, the switch of perspective is what the two columns in the tsble above show. But changing the perspective on a taxon doesn't change the taxon, when this is defined as a group of organisms. There are properties of the taxon that are independent of the perspective. Japanese knotweed is the same invasive plant whether it's called Fallopia japonica (Q899672), Reynoutria japonica (Q18421053) or Polygonum japonicum (Q15250539). Taxa exist independently of what we choose to call them. So it seems that Wikidata should be able to model this, but it may be too difficult. Peter coxhead (talk) 23:14, 19 March 2019 (UTC)
Actually, the "perspective on a taxon" includes the definition of the taxon, called "circumscription". Sometimes, a change in perspective just means a change of rank, or assignment to a genus, but it can also mean a change in size of the taxon, sometimes quite drastically. Without citing a taxonomic reference, there is no certainty what a scientific name refers to, although often enough it can be inferred from context. - Brya (talk) 05:22, 20 March 2019 (UTC)
@Brya: a person may have had or beeen known by multiple names during their lives. But we wouldn't say that "Carl von Linné" is an instance of person and "Carolus Linnaeus" is an instance of person, yet to paraphrase what you wrote above, any person's name is not only a name, but is also used to refer to a person. It's a serious category error to confuse the name of an entity with the entity. "Carl von Linné" and "Carolus Linnaeus" are names for the same person, just as Fallopia japonica (Q899672), Reynoutria japonica (Q18421053) and Polygonum japonicum (Q15250539) are names for the same taxon. Peter coxhead (talk) 23:14, 19 March 2019 (UTC)
"Carolus Linnaeus" is listed as an instance of "human". But humans are more or less fixed single entities, legally anyway, going through several development stages. There is a lot that can be said about names for humans, too much to go into: it is not a simple topic.
        Taxa are rather fluid, or more precisely "serially fixed", that is they are fixed in a particular taxonomic paper, but the next taxonomic paper may fix them differently, and so on, ad infinitum. There is also a lot that can be said about scientific names for taxa, but these are regulated in several Codes, each applying to certain groups of taxa. These provide order and certainty, as long it is recognized that one is dealing with multiple alternate realities.
        The only way to have one name for each taxon would be to adopt an official WMF-Taxonomy. The objections to this are obvious: 1) it would be an Original Research endeavour, while Wikipedia's have a NOR-policy; 2) at present all Wikipedia's make their own choices for taxonomy to be used in taxoboxes, and imposing a WMF-Taxonomy on them would be unpopular; 3) any WMF-Taxonomy would go out of date quickly. - Brya (talk) 05:54, 20 March 2019 (UTC)
Adopting one name for a taxon would, I agree, be completely wrong, and I certainly have never suggested it. Wikidata must represent what all reliable data sources say, whether these sources agree or not. I made two points, which I will repeat one last time:
  1. Wikidata should be accurate and make it clear that what are currently called instances of taxon are actually instances of taxon name. I still have no idea why this is opposed.
  2. Ideally, there needs to be some agreed way of representing taxa (for one thing, Wikipedia articles are usually about taxa, not taxon names). However, this is a difficult problem, it turns out, and no-one has yet demonstrated a working solution. As Brya rightly says, part of the difficulty is that taxa are not as clearly defined entities as, say, people. Maybe it can't be done within the constraints of Wikidata. (Representing alternative classifications in Taxonomy templates in the English Wikipedia involves a combination of ad hoc data "fixes", like skip and variant templates, plus special programming to respond to these data fixes. And it still causes problems that are currently under discussion.) If it can't be done in Wikidata, this needs to be made very clear, so that it's understood that Wikidata cannot be used for purposes that require taxon data (e.g. taxoboxes). However, it's not quite as problematic as Brya says above. Those alternative views that concern the placement or rank of a taxon, rather than its circumscription, leave the taxon (=group of organisms) unchanged.
Peter coxhead (talk) 13:50, 20 March 2019 (UTC)
Though a taxon may have several names, when you talk about a specific taxon name then you talk about one and only one taxon. Without an author, a name, a description, ect... a taxon is just a concept absolutely indistinguishable from another taxon, it is just an idea. The "instance of taxon" here must be understood as "instance of a specific taxon as defined and described under that name". This is absolutely not untrue. Christian Ferrer (talk) 22:37, 20 March 2019 (UTC)
A general point: it is not a requirement that a taxon have a name. It is not unheard off for a taxonomist to publish a description of a recently recognized taxon without naming it. Sooner or later, after hearing the responses of collaegues, he will follow this up by naming it (or not). - Brya (talk) 18:27, 21 March 2019 (UTC)

Comment[edit]

  • I would like to make a couple of comments from the point of view of a nomenclatural taxonomist. However I work with the ICZN code and the other four codes of nomenclature are different in some aspects.
    • A name on its own for the species level cannot be used without a genus. However names have an original combination and then can have multiple subsequent combinations. One way would be to have q items for every original combination and include on that page subsequent usages. This would then link to the q item of the current combination. This can likewise be done for synonyms. I am still only referring to species level only. For example the original combination for the mata mata is Testudo fimbriata, it was later moved and became Chelus fimbriata before its spelling was corrected (gender agreement) to Chelus fimbriatus. All this info would go on the q item for Testudo fimbriata with original refs, then link the item to the current species page for the Mata mata. As there are some 15 synonyms of the Mata mata you would need to do this for all of them. Which leads to a problem posed above which is that this is a lot of work.
    • Higher orders would be simpler but also follow the same principal for synonyms. It would still be a lot of work.
    • As noted above it would be easier to start this on small groups (at order level) to trial out the best way to do it before doing anything to complex groups such as vertebrates which can have 15-20 synonyms per species.
    • I agree that you should list the type specimen and the type locality.
    • This would be a high maintenance and highly specialised endeavour, do you really have the editors that can do this at a significant rate, and have the skills to do it. If not and be honest this is a massive undertaking and would require detailed policies for new editors to learn exactly what your doing.
    • Apart from the initial undertaking this is also a significant undertaking in terms of maintenance, in reptiles over the last 20 years the number of species has gone from 6000 to 10500, with many new combinations and synonymies proposed. This is just the reptiles. The people doing this also have to maintain it, this can mean up to 10 or even more edits per year per page that would be major updates that would effect multiple pages at the same time. Of course this is actually ignoring anything outside the major divisions, so I have ignored anything prefixed by sub or suffixed by inae.
    • Lastly you will need your editors of this to be very aware of the difference between nomenclature and taxonomy, to truly understand terms such as type, taxon, and many more, ie memorise the glossary of the code. You are going to have to make some decisions, there are many instances of multiple papers coming out with differences of opinion on what the correct nomenclature for a group is. How will you decide which one to use? In other words some groups are extremely dynamic and in a state of flux.
  • In summary although some great ideas, I think this idea is a big ask of the relatively few people who are well vrsed enough in the complex field of nomenclature to actually do it.
Scott Thomson (Faendalimas) talk 20:00, 19 March 2019 (UTC)
For plants there is IPNI. When it is willing to collaborate with us, a lot of the work can be shared. I personally have an 80MB database with normalised data bringing literature author references et al together for succulents. I am of an opinion that the only copyright IPNI has is the copyright on its original database, my database is based on IPNI but is a distinct database in its own right. I am willing to make it available under cc-0. Thanks, GerardM (talk) 09:42, 20 March 2019 (UTC)

MESH ID should be split?[edit]

--Vladimir Alexiev (talk) 13:43, 17 March 2019 (UTC)

I agree with this, basically. But when it comes to "absolutely no need to scrape it", then I disagree. I can see use cases for having the information on Wikidata (which of course motivates the proposal, filed under "authority control" even though it is not directly about an identifier). One that I didn't mention on the proposal page relates to the WikiJournal, and some good kind of "hovercard" (see mw:Page Previews) for it involving MeSH. Charles Matthews (talk) 06:48, 18 March 2019 (UTC)

New tool: QuickCategories[edit]

Hi folks! I want to announce a new tool I’ve been working on: QuickCategories (documentation), a tool to quickly add or remove categories from pages. It’s not especially useful for Wikidata directly, but it’s kind of Wikidata-adjacent, so I still want to announce it here :D

I assume most people here are familiar with QuickStatements. Harmonia Amanda suggested that something similar for categories instead of statements would be useful, and so that’s what I built. You specify the page to edit and the categories to add or remove in a big text box:

Page 1|+Category:Category to add|-Category:Category to remove
Page 2|+Category:Category to add|-Category:Category to remove

Like in QuickStatements v2, you can use keyboard-friendly | or spreadsheet-copy+paste-friendly Tab characters as separators (or mix them). At the moment, there’s no support for running commands in the background (in that respect it’s more like QuickStatements v1), but I plan to add that in the future (hopefully soon).

You can also generate commands via a Wikidata query. For example, running this query lists all Members of Parliament of the United Kingdom whose Commons category is not a subcategory of commons::Category:Politicians of the United Kingdom. You can copy the last two columns of the results (in Firefox, hold down Ctrl while dragging the mouse across them) and paste them directly into the tool.

The tool supports all Wikimedia wikis, but it’s probably especially useful on Commons, that’s why for now I’m only announcing it there and here. Feel free to copy or crosslink the announcement on the village pump (equivalent) of other wikis you think might be interested, or let me know if you think I should do it. If you have any questions, please contact me on the tool’s talk page, preferably with a {{Ping}} (I don’t check my watchlist on Meta that often). --Lucas Werkmeister (talk) 21:57, 17 March 2019 (UTC)

Request for protect:Q179294[edit]

This page is being vandalized by User:Jesamsex and other IPs, socket puppets of User:Unypoly for a long time, by adding a duplicate Korean version article w:ko:환자 (역사) and separate other Asian language versions.--Zhxy 519 (talk) 01:38, 18 March 2019 (UTC)

Q56145599 means Eunuch public official. It is a subclass of eunuch. It is not vandalism.  – The preceding unsigned comment was added by 2001:2d8:e08e:4f67::12ef:40a1 (talk • contribs) at 03:50, 20 March 2019‎ (UTC).
Please ban this IP. It should be no doubt a socket puppet of User:Jesamsex.--Zhxy 519 (talk) 02:42, 24 March 2019 (UTC)

Wikidata:Database reports/Complex constraint violations/P935[edit]

Why does the second complex constraint does not yield any results? If I run the query on the talk page, I get 12000 results. 129.13.72.197 08:15, 18 March 2019 (UTC)

I think it was because the query was returning more than one field named "item". I've changed it from "SELECT ?item ?itemLabel WHERE {" to "SELECT DISTINCT ?item{" in order to match the first constraint. Hopefully it will pick it up in the next run through. *shrug* ElanHR (talk) 01:00, 20 March 2019 (UTC)
Ok, thanks, lets see.... 129.13.72.197 09:19, 20 March 2019 (UTC)
Looks like that was the issue! :) ElanHR (talk) 06:25, 23 March 2019 (UTC)

Washout of dam and bridge by Niobrara river[edit]

Any Nebraskans here? I tried to start making some sense of the flooding occurring from the Spencer dam blowout like my edit here U.S. Route 281 (Q2175059). How can an interstate blockage be modelled? Thx. Jane023 (talk) 09:13, 18 March 2019 (UTC)

@Jane023: Try significant event (P793) with point in time (P585). Snipre (talk) 10:53, 18 March 2019 (UTC)
Sorry, I think the best is
Snipre (talk) 11:05, 18 March 2019 (UTC)
Thanks - I ended up making a WP article for Spencer Dam (Q34942691) since it was done on dewiki through cebwiki (see? Cebuano wiki is good for these things!). I suppose the significant event on the interstate can be linked to the bridge that is gone (some memorial highway, can't find it though). What amess. Turns out the dam was scheduled to be decommissioned. Jane023 (talk) 11:58, 18 March 2019 (UTC)

Open Company Data Donation[edit]

As a side effect of one of my commercial projects I have curated a dataset of companies which I would like to donate. I started to build a company search engine (work in progress), but it might do more good for more people here at wikidata. Some of the columns which could be suitable for wikidata are : company name, company HQ address, founding date, number of employees(bracketed 1-50 50-200 ... 1000+ ) , gov business legal entity ID, founder names, list of references to the company in the news (not all of this data is visible in the search engine at the moment).

The data I derive from multiple sources: the homepage of the company, gov data repositories like companies house, and news written about a company and in some cases directly submitted or verified by the company owner.

I have >3million companies currently but we will probably want to filter it to only those with doubly verified information.

Rubenwolff (talk)Rubenwolff

@ChristianKl: Not sure what kind of permissions this bot would need but I went ahead and named it https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/CoRepoBot Rubenwolff (talk) 16:28, 18 March 2019 (UTC)

Calabi–Yau threefolds in $${\mathbb {P}}^6$$ P 6[edit]

The title of the item at first glance looks like some sort of vandalism, however Calabi–Yau threefolds in ℙ⁶ (Q59472728) is absolutely legit but our quickstatments bot is not math-friendly it seems. See the original scientific article. Is it serious enough to file an issue ? Kpjas (talk) 12:42, 18 March 2019 (UTC)

Both labels and titles are supposed to be unicode and not math-ml or wikitext formatted. It's the problem of the person who enters data to provide it in unicode and not quickstatements to do that conversion. ℙ⁶ is well supported by unicode. ChristianKl❫ 13:06, 18 March 2019 (UTC)
@ChristianKl: but mass importers rarely review what lands eventually in WD items, do they ? Kpjas (talk) 13:33, 18 March 2019 (UTC)
@Sohmen: Can you see that in future the data you enter is unicode? ChristianKl❫ 15:52, 18 March 2019 (UTC)
I used SourceMD to enter the article which only lets you enter DOIs. I filed an issue for this at the SourceMD repository. --Sohmen (talk) 15:31, 21 March 2019 (UTC)

Wikidata weekly summary #356[edit]

Removing mandatory constraints when data quality is low?[edit]

As I just got into a little edit war at Common Database on Designated Areas ID (P4762) with @Abián: and @Sjoerddebruin: - do we now remove mandatory contraints simply because our data does not match them? In this case there are currently 2000+ items which lack the second identifier which they have, we "only" need to fix our data to make that constraint covered again. In this case, it is just one week now that @GPSLeo: added the only one identifier, so this I would consider this "work in progress" (see the history of Wikidata:Database reports/Constraint violations/P4762). And even if there really were so many violations for months/years - hiding the fact that our data is incomplete will not solve the problem! Only if they show prominently, someone will choose to work on them. 16:48, 18 March 2019 (UTC)  – The preceding unsigned comment was added by Ahoerstemeier (talk • contribs) at 17:48, 18 March 2019‎ (UTC).

Can't you just make it "non-mandatory"? I would think "mandatory" implies it needs immediate fixing (within hours). If it's not that urgent, it shouldn't be marked mandatory. ArthurPSmith (talk) 17:48, 18 March 2019 (UTC)
@Ahoerstemeier: don't edit war. A constraint that has 2172 constraint violations shouldn't be marked as mandatory. Solution is quite simple. You clean up the constraints so the number is zero and you add the mandatory constraint again. Everyone will be happy. Multichill (talk) 18:19, 18 March 2019 (UTC)
Great, put the work and blame on the messenger. So what we need is a new constraint type "could be mandatory once someone cleans up the data". 11:35, 19 March 2019 (UTC)
No, we don't. Matěj Suchánek (talk) 18:39, 19 March 2019 (UTC)
There are three cases: A constraint which has some exceptions in the real world already, a constraint which has zero violations in the real world but many here due to lack of maintenance , and a constraint which has no violations here. But OK, I see nobody cares about how to improve the data, removing the warnings is a solution for most it seems. Ahoerstemeier (talk) 09:55, 20 March 2019 (UTC)
It's still a constraint and violations are highlighted immediately in the UI. Once the current violations have been addressed it would be fine to make it 'mandatory' again. Leave a note on the talk page as a reminder so anybody can fix it at the right time. ArthurPSmith (talk) 17:43, 20 March 2019 (UTC)

East Jerusalem[edit]

Hi, I have a problem with places located in the Israeli occupied territories, that is, the territories Israel has occupied since the 1967 war.

After 1967, Israel has unilaterally annexed part of East Jerusalem, this annexation is accepted by exactly 0 other countries. My 2 cents is that we should follow what the international community says, and therefore should not say that they are in Israel.

Comments? (It was partly discussed here Huldra (talk) 20:55, 18 March 2019 (UTC)

In these situations, we should include all the most relevant points in the data. I outlined many of the relevant issues on relating countries and territories and subdivisions at Wikidata:Project_chat/Archive/2018/10#Countries_and_their_subdivisions_and_territory. We need to be able to specify recognition, administration, claims, control, domestic status, subdivision structure source, etc. so that any relevant attribute can be queried. The difficulty is figuring out a data model. In the case of East Jerusalem, we must include the data that the area is administered, controlled, and claimed by Israel, and the data that it is not recognized internationally as being part of Israel. We need to establish a broad data model for dealing with this and the dozens of similar cases, rather than simplifying each situation to pick whichever side of the conflict is more popular among the people arguing the point at the moment. --Yair rand (talk) 04:29, 19 March 2019 (UTC)
Do not we already have enough qualifiers to represent both point of view?--Ymblanter (talk) 20:33, 19 March 2019 (UTC)
Thank you Yair rand, that was interesting. And yes, I absolutely agree; we should get a consensus for this, as it concerns all the articles in East Jerusalem (ie, quite a lot).
Actually, we are in a somewhat similar situation for the articles about the Golan heights: also occupied and annexed by Israel since 1967, while the international community still consider it a part of Syria.
To start with "the top" question, that is, what country they are in:
If (and it's a big IF) we have a country (P17) label, then we should have, say 2 answers;
first: Country A (with the subfield that this is according to the international community, with the exception of country 1, 2 and 3)
second: Country B (with the subfield that this is according to country 1, 2 and 3)
Or: We do NOT use a country (P17) label at all for these places, but only the territory claimed by (P1336) label. Then we will still need a field indicating who accepts the claim. Comments? Huldra (talk) 20:48, 19 March 2019 (UTC)
To clarify the relevant scope here: I'm talking about every territory held in every one of the 165 military occupations listed at w:List of military occupations plus all prior military occupations, all territorial disputes, every state with limited recognition (current and former), and so on. These must all share one broad model.
country (P17) can't be limited to detailing recognition, unless another property stores other data of how the area is related to countries (control, administration, etc).
Regarding recognition itself, the "international community" is too vague to use as a single point anywhere. The individual countries' positions would need to be listed. That would take up a lot of space, though, so perhaps recognition should be split into a separate item which could be referenced by qualifier. However, that might make it a bit harder to query, so it's not ideal... --Yair rand (talk) 22:07, 19 March 2019 (UTC)
I agree that the scope should be all present disputed territories; I am not sure that I agree that it should include all pasts form of disputes.
I think we absolutely need another property which included who support the claim. Otherwise we would show that, say 2 countries have the same claim to a territory, without (in the most extreme case) telling the reader that one claim is supported by every country on the planet - 1, the other claim is supported by 1 country. If we don't have a "qualifier", we would be giving each claim "equal weight", and in effect misleading our readers. Approximate numbers could be used, where the individual countries' positions could be listed as a sub property, Huldra (talk) 20:49, 20 March 2019 (UTC)
Approximating numbers seems like it would be subject to dispute. Why approximate when we can be precise about which countries in particular support a claim? Do you agree that we also should include information on which country actually governed an area at a particular time? For example, almost the entire world recognizes Taipei as being part of the People's Republic of China, although Taiwan (ROC) actually governs the area, and all countries that recognize it as being part of Taiwan also recognize Beijing as part of Taiwan, but we wouldn't want Beijing to have the exact same statements as Taipei. --Yair rand (talk) 00:56, 21 March 2019 (UTC)
Do we have a property or qualifier for what country has de facto control of a territory? - Jmabel (talk) 15:12, 21 March 2019 (UTC)
No, I don't think so. There probably should be, but it's quite a complicated thing. Is Autonomous Republic of Crimea (Q756294) a territorial entity controlled by Russia? Russia doesn't consider that administrative division to exist, as it considers the Republic of Crimea (Q15966495) to be the relevant subdivision, whereas Ukraine wouldn't consider itself the rightful government of Republic of Crimea (Q15966495), since it doesn't recognize that subdivision. There are also different degrees of "control". Is the territory run by the military, or does the country run a functioning civil administration for the area within the country's regular framework? In internal disputes by subdivisions, one side typically administers the area, but there are (usually) no militaries involved. In some areas, a military can control an occupied area without the country setting up a local government to properly administer it. "Control" and governance/administration are sort of separate things, but sometimes closely related. --Yair rand (talk) 00:13, 22 March 2019 (UTC)
@Yair rand: I think that would come down to what we consider acceptable citations for de facto control. But China presents a clear example: two governments both claiming the same territory de jure, with one in de facto control of the bulk of the territory, and the other in de facto control of the remainder (Taiwan and a few small islands in the South China Sea). - Jmabel (talk) 01:21, 22 March 2019 (UTC)

Incorrect Wikisource links[edit]

We have a number of items with links to Wikisource, for example:

which link to works about the subject of the item, not to an equivalent Author: namespace page.

How can we fix this? And how can we use an edit filter or similar to prevent recurrence? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:46, 18 March 2019 (UTC)

Fix by moving the Wikisource link to described by source (P1343)? Ghouston (talk) 22:08, 18 March 2019 (UTC)
and optionally create an article like Elliott, Stephen (Q28032076), although it seems like overkill for a one-paragraph encyclopedia article. Ghouston (talk) 22:53, 18 March 2019 (UTC)
You'd need to create the data item regardless in order to use described by source (P1343). Beleg Tâl (talk) 23:07, 18 March 2019 (UTC)
Not necessarily, Albigence Waldo Cary (Q18819010) already has such a statement that just links to Appletons' Cyclopædia of American Biography (Q12912667). Ghouston (talk) 00:03, 19 March 2019 (UTC)
Can described by source (P1343) have a URL qualifier? There's also described at URL (P973). Ghouston (talk) 00:09, 19 March 2019 (UTC)
@Ghouston: Albigence Waldo Cary (Q18819010) is set up incorrectly. The link to Wikisource is to a biographical article which will have its own publication data that need to be included. The person who is the subject of the article will not have publication data. So you cannot add a Wikisource link that way. It may seem like "overkill" to you, but unless the full information for the citation of the article is included, then citation data for the article cannot be pulled from the data item. See for example DGRBM-1870 / Oedipus (Q47507582), which contains full publication data allowing the linked article to be cited, by using the data in the corresponding data item. With all the publication data available in the data item, a Wikipedian wishing to cite the article could use a tool to generate the citation, without having to manually retype all of the data. --EncycloPetey (talk) 01:58, 19 March 2019 (UTC)
I'm not sure, isn't the described by source (P1343) on Albigence Waldo Cary (Q18819010) that sources Appletons' Cyclopædia of American Biography (Q12912667) not also a valid way of doing it? You can add another qualifier for the page number, and there doesn't seem to be any further publication data. Ghouston (talk) 02:41, 19 March 2019 (UTC)
The described by source (P1343) linking is correct, but not the link in the Wikimedia links section of the data item. There is a lot of other publication data: identity / title of the work in which the article was included, volume / pages in the volume, date of publication, and author of the article. This should all appear in a data item about the article, regardless of the article's length. Every published work gets its own data item, from Leo Tolstoy (Q7243)'s massive novel War and Peace (Q161531) to the 17-syllable Frog Poem (Q11411329) by Matsuo Bashō (Q5676). Length of the publication is irrelevant. --EncycloPetey (talk) 03:00, 19 March 2019 (UTC)
An aside: persons on Wikisource can be either in Author space (if they are authors) or in Portal space (if they are not authors), but never in mainspace (unless the person is themselves a written work). Beleg Tâl (talk) 23:07, 18 March 2019 (UTC)
This is true on most Wikisource projects, but not all. The German Wikisource puts its Author pages in the Main namespace instead of in an "Author:" namespace. E.g. s:de:Johann Wolfgang von Goethe --EncycloPetey (talk) 02:01, 19 March 2019 (UTC)
i would not say "they are incorrect" but that the ontology is not settled. subjects of encyclopedic articles are notable at wikidata, so a migration path from wikisource page to wikidata item would be nice. we need a systemic way of indicating "depicts" or "is the subject of article" statements. and a author / portal subject infobox at wikisource. Slowking4 (talk) 11:37, 19 March 2019 (UTC)
The ontology is not at issue. If we allow such links to a Wikisource biographical article from a Wikidata item for a person, then the system fails whenever we have two different articles about the same individual on the same Wikisource project. Only a single link to a particular project is possible from any given data item. So this method would say that "link to the article about the person, unless there is more than one article about the person, in which case, (pick one of them?) (do it differently somehow?)". Any proposed system that breaks that easily is untenable. --EncycloPetey (talk) 14:08, 19 March 2019 (UTC)
Sounds like Wikidata's issues with the different spaces on Commons are not a problem unique to Commons. - Jmabel (talk) 16:14, 19 March 2019 (UTC)
"Any proposed system that breaks that easily is untenable." = sounds like wikipedia. the ontology is the issue. the fact that wikisource does not have a convenient "depicted" page for wikidata is interesting. maybe wikidata should create such pages, either in wikidata or wikisource. sources for those depicted people would then be citations. chapters in works in wikisource are citations. do not know why you would consider them a data item. that is until you roll out wikicite. Slowking4 (talk) 13:32, 20 March 2019 (UTC)

Template:Undent The ontology is not "broken", the wikidata item just was linked improperly to the Wikisource page (not everyone is well acquainted with every Wikimedia Project!). This is not different than people accidentally linking the wrong items together across two wikipedias. Compare ACAB-1 / Bell, Alexander Graham (Q21508901), which is a properly formatted page for an Appleton Cyclopaedia article. Circeus (talk) 15:00, 24 March 2019 (UTC)

A minor enigma[edit]

Hello. Q60300562 is a wedding gift (Q60965053) by Pablo Picasso (Q5593) to Guillaume Apollinaire (Q133855). How can I store this? The question comes from the Bistro. Maybe, I'm not sure, we can have significant event (P793)change of ownership (Q14903979) with object has role (P3831)wedding gift (Q60965053) and donated by (P1028)Pablo Picasso (Q5593) as qualifiers but I'm then left without knowing how to store Guillaume Apollinaire (Q133855) under that very same property. Should this be split under two totally different statements? Do we need a 'transatcion type' property? Thierry Caro (talk) 03:33, 19 March 2019 (UTC)

I like what you propose here. You could add a qualfer “owned by” to the change of ownership. - PKM (talk) 20:22, 20 March 2019 (UTC)
Yes. But the use of owned by (P127) under change of ownership (Q14903979) remains quite confusing, obviously. It may mean either the former owner or the new one, in my example either Picasso or Apollinaire. Of course, used together with donated by (P1028) set to Picasso, it becomes clearer that if owned by (P127) is set to Apollinaire, this guy must be the new owner, but still. Thierry Caro (talk) 20:20, 21 March 2019 (UTC)
@Thierry Caro: To me the actual enigma seems to be that so many people would use the vague significant event (P793) when there are dedicated properties ;). Ownerships (and their changes) are recorded through owned by (P127), so it's just a question of finding an appropriate qualifier. Why not use subject has role (P2868), it seems fine to me. Granted, that property's french label is somewhat odd here, but it just means "en tant que" applied to the subject of the claim. And that sounds quite right in conjunction with donated by (P1028). What do you think? --Nono314 (talk) 20:41, 22 March 2019 (UTC)
We would then have owned by (P127)Guillaume Apollinaire (Q133855) with donated by (P1028)Pablo Picasso (Q5593) as a qualifier. And what you are suggesting is subject has role (P2868)wedding gift (Q60965053) as another qualifier, right? Well, it is understandable to a human, but strictly speaking, isn't this saying that Guillaume Apollinaire (Q133855) (or that the fact that he is the owner), not the painting itself, is the wedding gift? This is a bit unclear to me. Thierry Caro (talk) 22:39, 22 March 2019 (UTC)
No, we have subject has role (P2868) applying to the subject of the claim and object has role (P3831) to the object. So if you use the former it is unambiguously about Q60300562 while the latter would be about Guillaume Apollinaire (Q133855). It is actually clear semantically speaking for machines, only humans may be distracted by the awkward wording. I think the english labels and descriptions for the properties make it very clear, but in french it is much less clear if not misleading as the subject is not always acting.--Nono314 (talk) 14:43, 23 March 2019 (UTC)
OK. Thank you. We've then found a solution and I have tried a better wording for both subject has role (P2868) and object has role (P3831) French labels. Thierry Caro (talk) 12:17, 24 March 2019 (UTC)

OCLC Control number (P243)[edit]

Currently this is an instance of Wikidata property to identify books. Can this be changed to be an instance of Wikidata property for an identifier?

(OCLC includes many more items than books, including all forms of published and manuscript material, realia, even service dogs.) It would be good to have this property to describe non-book items.  – The preceding unsigned comment was added by 128.103.224.4 (talk • contribs) at 16:01, 19 March 2019‎ (UTC).

Changed instead to Wikidata property for authority control for works (Q19833377). Do you have examples of other classes of items that are represented in Wikidata and have OCLC iDs? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:14, 20 March 2019 (UTC)

Q925929 Leroy P. Steele Prize[edit]

Could someone remove all the 61 awardees of this award (P166). It allows me to restructure this award in its composite parts. Thanks, GerardM (talk) 18:26, 19 March 2019 (UTC)

What to do if the same edition has multiple ISBNs?[edit]

Aubrey
Viswaprabha (talk)
Micru
Tpt
EugeneZelenko
User:Jarekt
Maximilianklein (talk)
Don-kun
VIGNERON (talk)
Jane023 (talk) 08:21, 30 May 2013 (UTC)
Alexander Doria (talk)
Ruud 23:15, 24 June 2013 (UTC)
Kolja21
arashtitan
Jayanta Nath
Yann (talk)
John Vandenberg (talk) 09:14, 30 November 2013 (UTC)
JakobVoss
Danmichaelo (talk) 19:30, 16 February 2014 (UTC)
Ravi (talk)
Mvolz (talk) 08:21, 20 July 2014 (UTC)
Hsarrazin (talk) 07:56, 9 August 2014 (UTC)
Accurimbono
Mushroom
PKM (talk) 19:58, 10 October 2014 (UTC)
Revi 16:54, 29 November 2014 (UTC)
Giftzwerg 88 (talk) 23:36, 1 January 2015 (UTC)
Almondega (talk) 00:17, 5 August 2015 (UTC)
maxlath
Jura to help sort out issues with other projects
Epìdosis
Skim (talk) 13:52, 24 June 2016 (UTC)
Marchitelli (talk) 12:29, 5 August 2016 (UTC)
BrillLyle (talk) 15:33, 26 August 2016 (UTC)
Alexmar983 (talk) 23:53, 28 August 2016 (UTC)
Finn Årup Nielsen (fnielsen) (talk) 10:44, 29 August 2016 (UTC)
Chiara (talk) 14:15, 29 August 2016 (UTC)
Thibaut120094 (talk) 20:31, 14 September 2016 (UTC)
Ivanhercaz | Discusión Plume pen w.png 15:30, 31 October 2016 (UTC)
YULdigitalpreservation (talk) 17:35, 10 November 2016 (UTC)
User:Jc3s5h
PatHadley (talk) 21:51, 15 December 2016 (UTC)
Erica (ohmyerica) (talk) 19:26, 1 January 2017 (UTC)
User:Timmy_Finnegan
Mauricio V. Genta (talk) 05:38, 12 March 2017 (UTC)
Sam Wilson 09:24, 24 May 2017 (UTC)
Sic19 (talk) 22:25, 12 July 2017 (UTC)
Andreasmperu
MartinPoulter (talk) 09:21, 20 July 2017 (UTC)
ThelmadatterThelmadatter (talk) 01:11, 13 September 2017 (UTC)
Zeroth (talk) 15:01, 16 September 2017 (UTC)
Emeritus
Ankry
Beat Estermann (talk) 20:07, 12 November 2017 (UTC)
Shilonite - specialize in cataloging Jewish & Hebrew books
Elena moz
Oa01 (talk) 10:52, 3 February 2018 (UTC)
Maria zaos (talk) 11:39, 25 March 2018 (UTC)
Wikidelo (talk) 13:07, 15 April 2018 (UTC)
Mfchris84 (talk) 10:08, 27 April 2018 (UTC)
Mlemusrojas (talk) 3:36, 30 April 2018 (UTC)
salgo60 Salgo60 (talk) 12:42, 8 May 2018 (UTC)
Dick Bos (talk) 14:35, 16 May 2018 (UTC)
Marco Chemello (BEIC) (talk) 07:26, 30 May 2018 (UTC)
Harshrathod50
 徵國單  (討論 🀄) (方孔錢 💴) 14:35, 20 July 2018 (UTC)
Alicia Fagerving (WMSE)
Louize5 (talk) 20:05, 11 September 2018 (UTC)
Viztor (talk) 05:48, 6 November 2018 (UTC)
RaymondYee (talk) 21:12, 29 November 2018 (UTC)
Merrilee (talk) 22:14, 29 November 2018 (UTC)
Kcoyle (talk) 22:17, 29 November 2018 (UTC)
JohnMarkOckerbloom (talk) 22:58, 29 November 2018 (UTC)
Tris T7 TT me
Helmoony (talk) 19:49, 8 December 2018 (UTC)
Naunc1
Shooke (talk) 19:17, 12 January 2019 (UTC)
DarwIn (talk) 14:58, 14 January 2019 (UTC)
I am Davidzdh. 16:08, 18 February 2019 (UTC)
Juandev (talk) 10:03, 27 February 2019 (UTC)
Pictogram voting comment.svg Notified participants of WikiProject Books

Some books have an ISBN for the printed edition and a different ISBN for the e-book. Others, like FRBR, Before and After: a Look at Our Bibliographic Models (Q56487853), have distinct ISBNs for the PDF, EPUB and Kindle version. In such cases, should I add a qualifier like applies to part (P518)  print edition (Q59466300) or applies to part (P518)  e-book (Q128093) to each ISBN? There are two issue:

  1. the ISBN-13 (P212) property constraints allow only one ISBN per item and
  2. currently, there aren't items like "PDF version", "EPUB version", etc. Create them is easy but I don't know if this is the best approach.--Malore (talk) 00:53, 20 March 2019 (UTC)
Side note: the "ping" to Wikiproject:Books did not work. There are too many participants, and when the number of participants passes a certain threshold (I do not recall what that threshold actually is), then participants are not notified. You must post in the Project's talk page to guarantee notification. --EncycloPetey (talk) 02:22, 20 March 2019 (UTC)
That threshold is 50 [2]. 129.13.72.197 09:30, 20 March 2019 (UTC)
"constraints allow only one ISBN per item" As I've often said; if the constraints are wrong; fix them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:10, 20 March 2019 (UTC)
I always make separate “version or edition” items for each ISBN/edition/distribution format, although I usually only add the editions I am actually using as references (generally the hardcover and/or ebook, especially when the ebook is online and searchable). - PKM (talk) 20:18, 20 March 2019 (UTC)
@Pigsonthewing:Before fixing the constraints I wanted to be sure there isn't a better approach like creating an item for each version (as PKM pointed out) or using a different property. --Malore (talk) 00:42, 21 March 2019 (UTC)

When a Wikipedia article is cited[edit]

I have found a peer-reviewed academic article, refereed paper Birmingham's new dental school and hospital – A real Peter Pan of dentistry (Q62116481), that cites a Wikipedia article. How can this be modelled, given that the subject of the equivalent Wikidata item is not what is cited? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:04, 20 March 2019 (UTC)

Sounds like another item about the Wikipedia article is needed :) ArthurPSmith (talk) 14:41, 20 March 2019 (UTC)
It would be a Wikimedia article page (Q15138389). Showing that the current practice of linking Wikipedia articles as sitelinks isn't sufficient to describe them to Wikidata standards? Ghouston (talk) 21:33, 20 March 2019 (UTC)
Good question. Citing the language edition item e.g. English Wikipedia (Q328) and using something like section, verse, paragraph, or clause (P958), title (P1476) or URL (P2699) as a qualifier could work. Do we have a way to model the citation of a work in a Wikipedia article? Simon Cobb (User:Sic19 ; talk page) 22:33, 20 March 2019 (UTC)
That seems sufficient for referencing. Otherwise, creating items for Wikipedia articles, the next thing you'd want is items for all its authors ... at least it would be more easily automated than for the academic journal articles :P Ghouston (talk) 11:24, 21 March 2019 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

I've done this, for now. I'm not convinced it's the optimal solution. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:26, 22 March 2019 (UTC)

elemento fusionado o borrado?[edit]

No se pudo guardar debido a un error. The save has failed. El enlace del sitio svwiki:Ahmad Yamani ya es usado por el elemento Q6248873. ¿Quizás el elemento se debe fusionó y/o borrado? No dude en preguntar en el "Project chat" si no está seguro.  – The preceding unsigned comment was added by Hayateouamioubalhi (talk • contribs) at 14:28, 20 March 2019‎ (UTC).

Translation (punctuation is weird, so it's hard to tell what part of this is the quoted error message)
Title: element merged or erased?
Could not be saved due to an error, "The save has failed. The sitelink svwiki:Ahmad Yamani is already used for element Q6248873. Perhaps the item ought to be merged and/or erased. Don't hesitate to ask at 'Project chat' if you are not sure." - Jmabel (talk) 16:34, 20 March 2019 (UTC)
Nothing here indicates what the user was trying to save. - Jmabel (talk) 16:34, 20 March 2019 (UTC)

Revision-deletion policy[edit]

Do we have a policy on revision deletion? If not, what should we follow? I somehow thought we had one, but I could not find any.--Ymblanter (talk) 20:41, 20 March 2019 (UTC)

Wikidata:Deletion policy#Revision deletionMisterSynergy (talk) 20:43, 20 March 2019 (UTC)
Great, thanks.--Ymblanter (talk) 20:46, 20 March 2019 (UTC)

Google Knowledge Graph issues[edit]

Hello! One reader of Slovak Wikipedia posed a question on why there are two persons (both of them having their Wikidata entry) who do not have date of death in Google Knowledge Graph (one of them was shown as 150 years old). However, date of death is included in their Wikidata entry. I just want to make sure there is no issue on our (Wikidata’s) part. Any further info (e.g. links) about Wikidata–Google Knowledge Graph relation are welcomed.--Lišiak (talk) 14:01, 21 March 2019 (UTC)

@Lišiak: Which two people have this issue? Jc86035 (talk) 14:10, 21 March 2019 (UTC)
@Jc86035: Q1027978, Q12035527.--Lišiak (talk) 14:18, 21 March 2019 (UTC)
Google makes their own decisions about what to sync and you shouldn't expect that everything gets synced automatically. Neither of the two has a reference for the claim about their date of death, which means it's not trustworthy data and it makes sense when it doesn't get picked up by the Google Knowledge Graph. ChristianKl❫ 17:14, 21 March 2019 (UTC)
@ChristianKl: Actually, Q12035527 has reference for his date of death, but I understand it is problem on Google's part and we are in the clear. I will try to find references for Q1027978, though. Thank you!--Lišiak (talk) 17:55, 21 March 2019 (UTC)
  • I noticed it a few weeks ago, a bug by Google, they had 150 year old and I added the birth and death date at the same time here in Wikidata. --RAN (talk) 12:55, 22 March 2019 (UTC)
  • So it's not just me that noticed that someone who has a death date on Wikidata doesn't have it on their Google Knowledge Graph even though they have a death date in Wikidata and Google Knowledge Graph has the birth date. — Jeluang Terluang (talk) 09:24, 23 March 2019 (UTC)

WORK IN PROGRESS[edit]

THIS IS THE PROJECT PAGE FOR A PROJECT CALLED WORK IN PROGRESS

"Work in Progress" is an ebook by Cliff Holden (published as a pdf file) ...

It was first printed and bound by the author on 7th March 1999.

A printed copy was presented to the Tate Archives in 2004.

Subsequently it was proofread and reformatted in 2011 by one of Cliff Holden's students.

The text may also be found on the author's website ...

http://www.cliffholden.co.uk

However it is the version dating from work done in 2011 which provides the starting point for this project.

https://upload.wikimedia.org/wikipedia/commons/c/c2/WORK_IN_PROGRESS_-_CliffHolden_-_07.03.1999.pdf

Wikidata:Project_chat#WORK_IN_PROGRESS

Bughub (talk) 16:19, 22 March 2019 (UTC)

@Bughub: It's not clear what you're asking here, please clarify Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:56, 22 March 2019 (UTC)
@Pigsonthewing: Hello Andy ! (User:Pigsonthewing) Is this the correct way to reach you ? My name is Douglas Westbury (User:Bughub) ... I am glad you have asked me to clarify what I am asking for because I am new to this kind of work ... and I am trying to learn the rules as quick as I can ... However whatever the rules may be ... I can assure you I am not in breach of copyright ... I have been working on this article offline with the author Cliff Holden for over twenty years ! Bughub (talk) 16:17, 22 March 2019 (UTC)
@Pigsonthewing: Hello Andy ! I am writing here to update you on changes I have been making ... but I have to confess I am still out of my depth ... so any help you can give me would really be appreciated ... I have written to "Permissions - Wikimedia Commons" (permissions-commons@wikimedia.org) concerning the permission information for the file I uploaded (https://upload.wikimedia.org/wikipedia/commons/c/c2/WORK_IN_PROGRESS_-_CliffHolden_-_07.03.1999.pdf) and I have a ticket [Ticket#2019032210007545] Bughub (talk) 19:07, 22 March 2019 (UTC)
@Pigsonthewing: At present the file is subject to speedy deletion unless it is relicensed according to the Commons licensing policy. Bughub (talk) 19:07, 22 March 2019 (UTC)
@Pigsonthewing: "This media file is missing evidence of permission. It may have an author and a source, but there is no proof that the author agreed to license the file under the given license." So my question is this : Can I relicense the file under the Creative Commons CC0 ? Will that make the problem go away ??? Bughub (talk) 19:07, 22 March 2019 (UTC)
Convenience link: File:WORK IN PROGRESS - CliffHolden - 07.03.1999.pdf. - Jmabel (talk) 20:04, 22 March 2019 (UTC)
No, claiming to offer a different license will not solve the problem. The issue is that if Cliff Holden is the author and copyright holder, then only Cliff Holden can offer such a license, and there is no evidence that Cliff Holden has offered such a license. - Jmabel (talk) 20:06, 22 March 2019 (UTC)
@Jmabel:I am trying to establish that this work is in the public domain
I do really think it is up to someone else to step forward and challenge me on this
Putting the interests of the overall wikipedia project to one side for a moment ...
I will certainly continue to disseminate and discuss this material ...
I will certainly continue to pay myself for the printing of the book and give it away freely to whomever I choose ... for them to use in any way they wish !!!
If I wanted to I believe I would be quite within my rights ... (whatever rights they might be) ... to ASSERT MY OWN CLAIM TO AUTHORSHIP HERE (all be it as a claim to "joint authorship" for myself together with Cliff Holden)
I would be prepared to do that if it solved the problem
But I don't want to
It was always understood between Cliff Holden and myself that the name of the author should be given as Cliff Holden (and that the book would be in the public domain)
So when I am asked to provide evidence that the "author or copyright holder" has "agreed to license the file under the given license" ... I don't think you really have any understanding of what it is you are asking for ...
Do you think anyone else knows more about this than I do ?
Then let them come forward and challenge me
Until then I will take it as an established fact that the licensing of the uploaded file should be as follows ...
Creative Commons license name : Zero Public Domain, "No Rights Reserved"
Abbreviation : CC0
The very last line of the first page of the document states quite clearly "copyright © CLIFF HOLDEN 2011". That's not "in the public domain". But discusison of copyright should take place on Wikimedia Commons, not here, on Wikidata, as it is there where the decision on its future will be made. It is still not clear what you are asking for here on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:01, 22 March 2019 (UTC)
Thank you Andy Mabbett ! It is so nice to hear that someone has actually opened the file and read the first page (by the way ... I should know what it says since I wrote it) Perhaps you would like to explain to me (somewhere else ... in some other thread) what you think Wikidata is for ?
WORK IN PROGRESS is a digital arts project initiated by User:Bughub
https://www.wikidata.org/wiki/Wikidata_talk:Project_chat#WORK_IN_PROGRESS
Bughub (talk) 21:32, 23 March 2019 (UTC)

Disambiguation[edit]

PROBLEMS ARISING FROM THE TITLE OF THE TEXT

It occurs to me that there may be some confusion caused by the name of the project "Work in Progress" ...

This is the title of the text "Work in Progress" (2011 ed.) [3]" written by Cliff Holden (1999).

https://en.wikipedia.org/wiki/Work_in_Progress_(disambiguation)

Bughub (talk) 22:03, 23 March 2019 (UTC)

Q6517416 and Q61881575[edit]

Should Q6517416 and Swedish noble family (Q61881575) be merged? --RAN (talk) 12:52, 22 March 2019 (UTC)

  • Isn't the latter more specific? - Jmabel (talk) 15:35, 22 March 2019 (UTC)
I think they serve two (slightly) different purposes: social classification = Q6517416, while family = some Swedish noble family (Q61881575). At least that's how I've seen it being used. Moebeus (talk) 16:07, 22 March 2019 (UTC)
  • I think nobility of Sweden (Q1065129) should be merged instead with Q6517416. I've updated all related items with better english labels and descriptions, as well as extra claims to make it clear what the difference between nobility of Sweden (Q1065129) and Swedish noble family (Q61881575) is. Dhx1 (talk) 07:07, 23 March 2019 (UTC)
    • ✓ Done I tried to streamline Norwegian, Danish, and Finnish families/social classes a bit as as well. Turns out Swedish nobility is divided in "introduced" and "unintroduced" families, so that adds a slight layer of complexity. Moebeus (talk) 11:36, 23 March 2019 (UTC)

Thanks! Yes, a bit confusing, but not as confusing as historic Swedish name places for parishes, villages, and farms, and other divisions, all with the sane name, all corresponding roughly to the same area, all at different times. --RAN (talk) 15:03, 24 March 2019 (UTC)

Requiring sibling properties only when the item is an instance of a certain type[edit]

So the PCGamingWiki ID (P6337) property has a bunch of violations (database report) caused by a required platform (P400). While this is true when the item in question is an instance of video game (Q7889), if it's a video game controller or something else it doesn't make sense for it to have a platform (P400).

Is it possible to require a platform only in the case where the item is an instance of a video game? I assume it'd be poor practice to have potentially hundreds or thousands of "exceptions" for the constraint. Would it be preferable to split PCGamingWiki ID (P6337) into separate properties for video games vs. companies vs. controllers?

Thanks, Nicereddy (talk) 18:00, 22 March 2019 (UTC)

Maybe a job for Wikidata:WikiProject ShEx? ArthurPSmith (talk) 20:39, 22 March 2019 (UTC)
Why not just make a Complex Constraint? 147.142.76.28 08:18, 24 March 2019 (UTC)

You may have reached this special page because the item you tried to edit wasn't fully loaded for label/description edits to work there.[edit]

How do i fix this?  – The preceding unsigned comment was added by Trade (talk • contribs) at 20:35, 22 March 2019‎ (UTC).

Wait till the page is fully loaded. Sjoerd de Bruin (talk) 21:24, 22 March 2019 (UTC)
This have lasted for more than a day. Surely, this can be how it's supposed to work? Trade (talk) 13:32, 24 March 2019 (UTC)
Could be a symptom of some hidden problem. Try appending ?safemode=1 to the URL and see mw:Help:Locating broken scripts. Matěj Suchánek (talk) 19:26, 24 March 2019 (UTC)

Q54933327 strange thing[edit]

There is a strange thing happening on Q54933327. There are three articles linked to this data, one on the pt.wiki, another on the es.wiki and another on the en.wiki. If you go to the article on the en.wiki and click on the hyperlinks, it'll redirect you to the correct articles on pt.wiki and es.wiki. If you go to the es.wiki article and click on the hyperlinks, everything is ok too. But on the pt.wiki, if you click to go to the en.wiki article it'll redirect you to an article on en.wiki which not even exist. I tried to edit Q54933327 to fix it, but I do not even know what is wrong. SirEdimon (talk) 04:00, 23 March 2019 (UTC)

Issue is now resolved.SirEdimon (talk) 06:02, 23 March 2019 (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. Matěj Suchánek (talk) 13:26, 23 March 2019 (UTC)

time zones[edit]

If you're interested in time zones and the way property located in time zone (P421) is used, I have started a discussion at Property talk:P421. (This is, again, the question of whether it's preferable to use time zones named for a UTC offset (Q17272482), named time zones such as Q941023, IANA time zones (Q17272692), or some combination.) Scs (talk) 10:20, 23 March 2019 (UTC)

items for box-header and box-footer portal subpages[edit]

Just saw that we have at least ~400 items for portal header and footer subpages like Portal:Contents/box-header (Q17434151) and Portal:Japan/box-footer (Q15614596). And pretty much all of them have instance of (P31)  Wikimedia portal (Q4663903) statements, along with corresponding descriptions in many languages (probably because they are in the Portal namespace). What would be the correct instance of (P31) statement here, Wikimedia template (Q11266439)? --Kam Solusar (talk) 16:51, 23 March 2019 (UTC)