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

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Edit

Problem with language

Hello. Sometimes when I am using title (P1476), I am writing the first letters of the language and select the correct one, but when I am trying to save it, I get an error message that it can recognize the langue. I can save after I do the same procedure 2 or 3 times. Xaris333 (talk) 01:31, 24 August 2017 (UTC)[reply]

I had this problem some time ago, but now it become better for me. May be you should try to enter a code (ISO) of language instead of its name? --Infovarius (talk) 11:46, 30 August 2017 (UTC)[reply]
Probably phab:T158058.--GZWDer (talk) 13:22, 30 August 2017 (UTC)[reply]

Dealing with our second planet

The bot on the cebuano Wikipedia is quickly building a second planet on Wikidata with all the geographical items that it is currently duplicating at high speed. I have just let a message to his operator here. If you want to help us and get us a relief of about two years in order to be able to merge all the unnecessary items, don't hesitate to add a kind message under mine to basically say that: 1. We really thank you for trying. 2. Seriously, whatever, it is resulting in a disaster that now has us need a break. Thank you in advance. Thierry Caro (talk) 21:56, 25 August 2017 (UTC)[reply]

@Thierry Caro, Lsj: new items without claims aren't that problematic as duplicates with claims.
Do we have major cities as duplicates?
If they have coordinates we can merge them, but if not then it is more difficult (both items should be filled correctly). d1g (talk) 22:10, 25 August 2017 (UTC)[reply]
There might be another solution that stopping the bot there. It would be stopping to create items for cebuano articles here. This Wikipedia is using an uncommon method to do its stuff, maybe we can do the same and adopt an uncommon solution to deal with it? Thierry Caro (talk) 22:17, 25 August 2017 (UTC)[reply]
We can delete all the cebuano-only item here and let them add links to Wikidata only in items that have another language that would not be Swedish. I don't know, but it's really time something should be done. Thierry Caro (talk) 22:19, 25 August 2017 (UTC)[reply]
 Supportnot bot-importing articles from cebwiki seems a simple pragmatic solution, indeed :) --Hsarrazin (talk) 23:18, 25 August 2017 (UTC)[reply]
 Support (I don't know enough about the ongoing/planned processes to fix the problem to decide.) It's disgusting to be forced to look up all place items in suggestions to find the useful one among cebwiki ones. --Marsupium (talk) 01:07, 26 August 2017 (UTC), 16:39, 27 August 2017 (UTC)[reply]
 Oppose Duplicate is Wikidata's inexorable trend. We don't need to prevent them in advance. Make them unsearchable is much worse. In addition, we don't exclude a single wiki.--GZWDer (talk) 05:38, 26 August 2017 (UTC)[reply]
 Support. At least in the Philippines, there is a duplication between ADM2 and PPL entries in GeoNames. I've been merging articles on the Cebuano Wikipedia and Wikidata items whenever I encounter them in the course of my Wikidata editing. This is getting quite tiring to be honest. —seav (talk) 07:38, 26 August 2017 (UTC)[reply]
 Weak support I agree with points by @GZWDer:, but geodata is difficult to unmess when it is messy or not-so-fresh. The best is to import them by desc population or area by area. It is easier to merge area by area, but not planet by planet. d1g (talk) 08:26, 26 August 2017 (UTC)[reply]
 Oppose we just discussed the problems we have with cooperation. This is really inappropriate. We first need to appreciate if we want to collaborate and this is just a side show, also it is the bed we made up ourselves. Thanks, GerardM (talk) 08:50, 26 August 2017 (UTC)[reply]
The user behind the cebuano bot is actually OK for us to stop creating items for its articles, if that may help us. Thierry Caro (talk) 12:37, 26 August 2017 (UTC)[reply]
 Support. This has been discussed enough already, I think. − Pintoch (talk) 14:17, 26 August 2017 (UTC)[reply]
 Support, I would not mind if the original databases were reliable, but they are not.--Ymblanter (talk) 18:31, 26 August 2017 (UTC)[reply]
 Support This has been going on for way too long. Unfortunately, I don't see any other option at the moment but to delete all cebuano-only articles related to geographic objects. Andreasm háblame / just talk to me 19:19, 26 August 2017 (UTC)[reply]
 Comment No real arguments, no clear examples in this thread. Lsjbot mentioned in the initial message is not operating on Wikidata, is it? Matěj Suchánek (talk) 20:00, 26 August 2017 (UTC)[reply]
User:Lsj was never active here and fled from svwiki recently. --Succu (talk) 20:13, 26 August 2017 (UTC)[reply]
Actually not "recently": ... My joy in contributing to Swedish Wikipedia has been killed by these discussions. Therefore, I leave the project until further notice.--GZWDer (talk) 23:09, 26 August 2017 (UTC)[reply]
As I said above about "region by region" @Matěj Suchánek::
Moscow oblast
Bekasovo (Q31913297) Bekasovo (Q4081294) - approximate coordinates
Lugovaya (Q35720921) Lugovoy (Q16672299) - both without population but with coordinates
This situation in other regions too.
We should write a program so that such "different" items are not created in first place.
90% of merges should be done by programs, only ambiguous edits should be left for humans. d1g (talk) 22:17, 28 August 2017 (UTC)[reply]
Архангельское is not a "small city" as ceb wiki claims, but a palace complex.
It would never have real ATE codes: Arkhangelskoye Estate (Q2861586) ОКТМО
ceb wiki has very little interest to capture such differences or lack resources to fix all mistakes d1g (talk) 22:26, 28 August 2017 (UTC)[reply]
 Support Mass imports from WP are a mess. Snipre (talk) 20:34, 26 August 2017 (UTC)[reply]
 Comment See ceb:Kategoriya:Articles without Wikidata item. Cc @Mr. Ibrahem:. --XXN, 22:15, 26 August 2017 (UTC)[reply]
I still thinks creating new items, which probably include many duplicates, is much better than having no items at all. As Wikidata is not compulsory, someone getting tired may just ignore them. The items ensure that everything that any wikipedia has written about has some record in wikidata, and can therefore be found and enhanced (including duplicate detection). Also User:Pasleim/projectmerge is a place to find possible (ceb-other wiki) duplicates (and thus find new links between wikipedia and geonames), which can not be used without existing items.--GZWDer (talk) 23:30, 26 August 2017 (UTC)[reply]
 Comment I think we should have done this with other parts of Wikidata that isn't useful for this project. disambigs, templates, project-pages do not fulfil any structural need at all here. It is only here for the interwiki, and that is not the purpose of this project. -- Innocent bystander (talk) 00:34, 27 August 2017 (UTC)[reply]
It is our purpose to support other Wikimedia wikis, including storing they interlanguage links. When will you finally understand this? Matěj Suchánek (talk) 07:31, 27 August 2017 (UTC)[reply]
And that has proved to be a bad idea. -- Innocent bystander (talk) 07:58, 27 August 2017 (UTC)[reply]
 Oppose Those items meet our notability criteria so aren't eligible for deletion. If you want to change to the notability criteria to allow us to start discriminating between articles we like and ones we don't, you should start an RfC because that would be quite a fundamental change. I think it would be a bad idea, once we start doing it for one Wikipedia, it makes it much harder to say we shouldn't do the same for other Wikipedias. One of Wikidata's purposes is to be able to provide structured data to Wikimedia projects, which means we have to deal with Wikipedias doing things we don't like. If someone on the Cebuano Wikipedia wants to start fetching data from Wikidata, how are they supposed to do that if we don't allow the items to exist?
The way this all happened is very frustrating but Lsj has said that Lsjbot is nearly done and once we're not getting a constant flood of new items, it will be much easier to clean things up. Most data in GeoNames is imported from other databases and therefore should have other IDs too (I've already added lots of IDs for other databases and I plan to continue doing that). All large databases contain errors but we have a way to deal with that: Mark the affected statements as deprecated (and preferably also report the errors to the databases they were found in).
- Nikki (talk) 09:05, 27 August 2017 (UTC)[reply]
@Nikki: this is not about discrimination but about number of editors with capability to merge ceb items and their merge speed.
If we were merging English planets it would be much quicker. d1g (talk) 20:00, 27 August 2017 (UTC)[reply]
@Nikki: d1g (talk) 20:00, 27 August 2017 (UTC)[reply]
 Oppose What Nikki said. Sjoerd de Bruin (talk) 09:09, 27 August 2017 (UTC)[reply]
 Oppose I don’t like that this mass import happened, but deleting the items now would definitely be the wrong thing to do IMHO. And stopping the import now also would be awkward – leaving us with a partial but incomplete set of items (which, to people who stumble upon it later, might well be mistaken for a complete set of items). So I think the best course of action now is to finish up the import (preferably with a healthy throttle, so it doesn’t put so much strain on the servers – there’s no hurry), and then see what needs to be cleaned up. —Galaktos (talk) 12:47, 27 August 2017 (UTC)[reply]
 Comment we can find duplicates items by many tools or sparql like: 
SELECT DISTINCT ?item1 ?item1Label ?item2 ?item2Label ?value 
{
	?item1 wdt:P1566 ?value .
	?item2 wdt:P1566 ?value .
	FILTER( ?item1 != ?item2 && STR( ?item1 ) < STR( ?item2 ) ) .
	SERVICE wikibase:label { bd:serviceParam wikibase:language "ar,en" } .
}
LIMIT 100
Try it!
--Mr. Ibrahem (talk) 14:40, 27 August 2017 (UTC)[reply]
 Comment why are you creating them as duplicates and leaving it to others to clean up?
--- Jura 16:46, 27 August 2017 (UTC)[reply]
Two items with identical GeoNames ID (P1566) are not always exact duplicates - thanks to the mess propagated from some Wikipedias mixing municipalities and settlements in one article, we can't say with certitude without a proper individual review if a value of GeoNames ID (P1566) in such item is 100% correct. --XXN, 10:33, 28 August 2017 (UTC)[reply]

What would be a query to display a map of all the cebuano-only items within less than yyy kilometers from location Qxxx? It would give us a sense of how big the problem is around our favourite personal locations. Maybe this would shift opinions one way or another. Thierry Caro (talk) 17:53, 27 August 2017 (UTC)[reply]

 Comment Don't delete as they are notable, but stop the import for now so we can at least clean up the current mess. Especially stop )or better remove) to import elevation above sea level (P2044) which is total bogus (see e.g. Khao Luang (Q31687791)), and add all the missing imported from Wikimedia project (P143) - many items in Thailand did not have them. It would be great if we could match the corresponding database entries from Geographic Names Server (Q1194038) which was the original source of most of them, but Geonames did not keep the IDs - the coordinates in GNS are better than those in geonames, and have less duplicated. A way to mark the items which haven't been checked by a human would also be great - so that e.g. in a query fors hill only those verified will show up. Ahoerstemeier (talk) 08:33, 28 August 2017 (UTC)[reply]
 Support For the UK this question comes up most sharply at the level of village (Q532) vs civil parish (Q1115575).
There are currently about 10,500 civil parishes in England. For about 8,000 we currently have a joint item with some form of human settlement (this is the typical situation if the two have the same name); about 2,000 have their own item (usually where the parish does not have exactly the same name as any of the settlements it contains); and about 300 which have not yet been identified to items here.
Having two separate items introduces a difficulty with sitelinks from en-wiki to Commons. In such cases, the en-wiki article will usually be linked to the item for the settlement here; whereas the Commons link will tend to go to the whole parish (as the category will tend to include views from all across the parish, and having a solid representation of the parishes, being the lowest level of the official administrative hierarchy, is important in the automatic placing of images from Geograph, Wiki Loves Monuments, or other sources where the images come with geotags).
In the long run we may end up creating more items here that are separate for parishes and settlements. But in the short run, the priority is to get a solid list of CPs, solidly matched to Commons and vice-versa. And there's still a lot of work to do, simply to get to there -- eg: live CPs not yet identified to items (~ 300); items marked as CPs that are not matched to a current live CP - these may be former CPs, unmatched CPs or simply mistakes (~ 600); CPs without a Commons category (~ 300), CP Commons cats with /more/ than one incoming link (~ 90); historical data to try to clarify; plus the latest crop of official changes to integrate (mergers, boundary changes, splits, renamings etc).
This is what needs to be focussed on for the time being, in a controlled way -- at this stage the creation of lots of extra items would be really not helpful. For the time being the relevant role of an item can be distinguished on a statement by the qualifier P794 (P794) or now more preferably subject has role (P2868) -- as done on Ab Kettleby (Q3490381) for example for the GeoNames ID (P1566) and TOID (P3120) statements. (It is also worth noting that many external sites also treat the parishes and settlements together, so for linking to them it is quite useful to have the one combined item for the external link statement to be on).
I accept that it may make sense in time to split some of these items. But I suggest that it is useful to do that no more quickly than the corresponding categories are split on Commons. That in turn is likely to be a slow manual job, as there doesn't seem to be any obvious way to automate it. And it may not even be desirable on Commons, if users want to be able to see all images from both the settlement and the parish on the one page, or indeed if the boundaries of the settlement are fuzzily defined, and it is hard to say which images belong to it or not.
So to summarise: (i) in this area, for the time being, there is real value in trying to get as close as we can to a 1:1 match between Wikidata items and Commons categories; (ii) there is a lot of work to do simply to debug what we already have; (iii) splitting these items creates significant extra difficulties of its own, and significant extra work to sort out, for no urgent need, getting in the way of other work which is much more pressing and useful.
Therefore, for the time being, whenever I see a parish item, with sitelinks only to sv-wiki and ceb-wiki, and no distinct Commons cat, I shall be marking it instance of (P31) Wikimedia duplicated page (Q17362920). Jheald (talk) 14:20, 28 August 2017 (UTC)[reply]
Note deleting these item does not make this better. It's Wikidata's practice to have seperate items about different but related concepts, like protein/gene, given name/surname, work/edition, where Wikipedia tend to conflate them.--GZWDer (talk) 15:59, 28 August 2017 (UTC)[reply]
 Oppose Deleting is definitely be the wrong thing. It is Wikidata's job to provide correct data. It is not the job of cebwiki to pay attention to other Wikipedias or to make the the work in Wikidata easier.--Cavaliere grande (talk) 14:52, 29 August 2017 (UTC)[reply]
We can provide correct data without these items. It's not Wikidata's job to be beholden to cebwiki, if it doesn't suit us here. Jheald (talk) 18:43, 29 August 2017 (UTC)[reply]

LinkedIn company profiles

We have P2035 (P2035), but no equivalent for company profiles on LinkedIn, like https://www.linkedin.com/company/kc-tmo. Various kludges are used to hold such URLs, with little consistency.

Should we:

  • modify the existing property, to be simply "LinkedIn profile URL"
  • create a companion "LinkedIn company profile URL" property
  • create an external-ID type property?

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:30, 26 August 2017 (UTC)[reply]

I would prefer to have two external-ID properties. One for companies and one for persons. ChristianKl (talk) 15:30, 26 August 2017 (UTC)[reply]

Two external ID properties are not an option: we have a URL property for LinkedIn profiles for a reason - that being that there is no single pattern from which we could extract a formatter URL. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:22, 31 August 2017 (UTC)[reply]

Life span

We have life expectancy (P2250) for „life expectancy for this group or species”. Any ideas how to express the maximal observed life span of a living being? --Succu (talk) 19:57, 26 August 2017 (UTC)[reply]

@Succu: I think that we should have a special property for that. Tubezlob (🙋) 15:35, 28 August 2017 (UTC)[reply]
@Succu, Tubezlob:I created the proposal https://www.wikidata.org/wiki/Wikidata:Property_proposal/highest_observed_lifespan . ChristianKl (talk) 18:12, 31 August 2017 (UTC)[reply]

Multi lingual support for Wikidata and SQID

Hoi, as it seems that SQID is one of the preferred tools, it is important to consider its support for other languages. Technically it does not. It only uses content as it happens to be in Wikidata. Consider this for instance. I have chosen Russian as a major language with major support in Wikidata.

My question to us all is. How can we raise our game and properly support other languages. Thanks, GerardM (talk) 06:48, 27 August 2017 (UTC)[reply]

@GerardM: what do you mean by "not supported"? I looked at Russian interface and found very little not-translated things (mainly, names of parameters). --Infovarius (talk) 12:32, 30 August 2017 (UTC)[reply]
The software itself shows texts in English only. The data that is in Wikidata itself is whatever label is provided. This is not about Wikidata, it is about the software that is SQID. Thanks, GerardM (talk) 13:43, 30 August 2017 (UTC)[reply]

Using a bot to fix statement with Gregorian date earlier than 1584

Some time ago User:Addshore tagged a lot of date entries with statement with Gregorian date earlier than 1584 (Q26961029) as part of phab:T105100. This was always meant to be the first step in the process to clean this up. I'm considering using a bot to fix the obvious cases to reduce the huge backlog. Approach:

The bot would change the calendar from Gregorian to Julian and remove statement with Gregorian date earlier than 1584 (Q26961029) (example edit). Is this approach correct? Some queries to get an idea of the numbers:

Feedback appreciated. Wouldn't want a bot to do 30.000+ edits and realize later the approach was incorrect. Multichill (talk) 12:25, 27 August 2017 (UTC)[reply]

It's always been agreed that there is no year 0 between AD 1 and 1 BC, or equivalently, 1 CE and 1 BCE. There was no consensus about whether, when using an all-numeric date format, 1 BCE should be represented as 0 or -1. Dates probably were entered incorrectly during the period of no consensus, so all BC dates should be checked. The consensus now is that when using RDF, 1 BCE is 0, but when using JSON, 1 BCE is -1. When using the user interface, always use the letters BC or BCE for years before 1 and never use 0 or a negative sign. See Help:Dates. Jc3s5h (talk) 13:17, 28 August 2017 (UTC)[reply]
The problem was explained here : phab:T129823. This means that every date BC with a precision of 7 (year) and higher (month, day ..) needs to be checked manually and should be out of scope for the bot. I am not sure for precisions decade and century : some rule should be made (decade 450BC : ok, decade 451BC : manual check). Other precisions can be processed. --Melderick (talk) 16:37, 29 August 2017 (UTC)[reply]

Announcement: Fallback indicators hidden on variant fallbacks

Hello all,

we’ll be deploying a minor change to the Wikidata interface soon. If your interface is set up in a language other than English, when you view an entity page, you can see entity labels in other languages than the one you selected, according to language fallbacks (e. g. Austrian German users might see German labels if there is no Austrian German label, or even English labels if there is no German label either for an entity). The language of the label being displayed is shown in a small indicator, e. g. Douglas Adams English. From August 29th forward, that indicator will be hidden by default if the user language and the language of the label are variants of the same language, e. g. if the user interface is in Austrian German and the label is in German.

If you don’t like this change, you can override it by adding a small piece of code to your your common.css. If you encounter any problem with this change, feel free to leave a comment under this Phabricator ticket.

Best regards, Lucas Werkmeister (WMDE) (talk) 14:03, 28 August 2017 (UTC)[reply]

Small change: it's not going to happen today, but tomorrow, August 30th. Lea Lacroix (WMDE) (talk) 12:10, 29 August 2017 (UTC)[reply]

Wikidata weekly summary #275

Here's your quick overview of what has been happening around Wikidata over the last week.
  • WikidataCon
    • The organization team is still looking for sponsors to support the event and provide even more awesome stuff to the attendees. If your company can support the WikidataCon, please get in touch with Lydia.
    • Seeing the enthusiasm of the community for the WikidataCon, we raised our attendees limit from 150 to 200 persons. The last tickets will be released on September 1st. People who registered on the waitlist will be notified when a ticket is available.
    • The program committee is currently reviewing and organizing the submissions. We will contact the speakers soon, and publish the program in the beginning of September (around 6th).
    • We're looking for a keynote speaker who could bring an external point of view on ontologies. If you know interesting people, feel free to help
  • Development
    • Worked on fixing the technical glitch in the UI (phabricator:T173543)
    • Did polishing on the Constraint Checks gadget (for example phabricator:T173738)
    • Worked on caching constraints checks results which is needed to enable constraints checks for all logged-in users (phabricator:T173696)
    • Made progress on checking constraints also on qualifiers and references (phabricator:T168532)
    • Worked more on making it easier to see when input in a property or value input field is not recognized (phabricator:T170531)
    • Fighting with load issues in the job queue (phabricator:T173710)
    • Looking into not showing language fallback hints for dialects to make the UI less cluttered for them and make it less necessary to enter labels and descriptions for them (phabricator:T174318)
    • Wrapping up our experiments with the new front-end technologies

You can see all open tickets related to Wikidata here.

What does "number of persons per QID" means? There are a lot of Johns with QID 7? Syced (talk) 07:38, 30 August 2017 (UTC)[reply]
  • Yes, but 6 not 7, more precisely with a QID between Q5500000 and Q6499999 [1].
    The milestone Q38000000 mentioned above as well has a qid of 38,000,000. If you break this down into 38 parts of 1,000,000 (last one would be from 37,500,000 to 38,499,999), it attempts to estimate how many items there are with P31:Q5 in each. The chart shows that there is a noticeable difference before and after Q30000000. A bit silly as an approach. You can do the chart also with P31=Q5 directly. It takes longer to run, but gives a similar chart. It should probably use FLOOR() instead of ROUND().
    --- Jura 07:58, 30 August 2017 (UTC)[reply]

strange history bug

it should be red and decrease in size as usual

Purge doesn't help. d1g (talk) 05:46, 29 August 2017 (UTC)[reply]

If they update the content model, the raw page size might increase even if data is removed from an item. This is more likely to happen after long times without any edits, as in this case. —MisterSynergy (talk) 06:01, 29 August 2017 (UTC)[reply]
See Help:FAQ. Matěj Suchánek (talk) 13:59, 29 August 2017 (UTC)[reply]

How to narrow down imprecise dates

Many dates, like birth / death dates for people or creation dates for artworks found in literature do not fall into neat day/month/year/decade/century precision. Commons c:template:Complex date template (used on 3M pages) lists many of the ways one can specify such dates. Many of the complex dates can be expressed on Wikidata using sourcing circumstances (P1480), start time (P580), end time (P582), earliest date (P1319), latest date (P1326) qualifier properties, however many dates used on Commons can not be (AFAIK) expressed using current model. For example:

  • second half of 9th century
  • early 10th century
  • mid 9th century
  • spring of 1599
  • third quarter of 8th century

Is there a way to express such dates on Commons? And if not than should we create a new qualifier to express them or shall we extend the use of sourcing circumstances (P1480), applies to part, aspect, or form (P518) or some other existing one. --Jarekt (talk) 15:10, 29 August 2017 (UTC)[reply]

Couldn't you add "earliest date:750/latest date:775" to express "third quarter of 8th century"? -- Innocent bystander (talk) 15:28, 29 August 2017 (UTC)[reply]
 Support for adding "earliest date:750/latest date:775" for "third quarter of 8th century".
"early", "mid", "spring" etc. are more tricky though. I think the main problem here is information loss due to back and forth translating. We could translate them to explicit dates and use broad spans, e.g. date of birth: "spring of 1599" ->
⟨ subject ⟩ date of birth (P569) View with SQID ⟨ 1599 ⟩
earliest date (P1319) View with SQID ⟨ 1599-01 ⟩
latest date (P1326) View with SQID ⟨ 1599-03 ⟩
(1599-03 is inclusive, hence broad). (RKDartists (Q17299517) does something similar when they assume dates of birth to be in a span of some days (I don't know their cut off) before dates of baptism.) object named as (P1932) can be used to cite the original wording (actually the same example at Property talk:P1932#Creation discussion). But I can imagine that something in between the machine-readable explicit dates and the human imprecise object named as (P1932) could be useful, too. Retranslating the "spring" translation to human language brings information loss, object named as (P1932) is not useful for present localized versions of for example a value in German "geboren im frühen August". A new qualifier could supply this, perhaps in addition to earliest date (P1319), latest date (P1326) and object named as (P1932) the broad machine-readable explicit dates. I'm undecided if an extended sourcing circumstances (P1480) should do that. I don't like that intermediate solution a lot, but can't think of a better one right now. --Marsupium (talk) 16:55, 29 August 2017 (UTC)[reply]
The names of seasons (spring, summer, autumn, winter) have different meaning in the northern and southern temperate zones. Other concepts tend to be used in the tropics. Jc3s5h (talk) 17:09, 29 August 2017 (UTC)[reply]
Yes, and 1599 is in Little Ice Age (Q190530), so the date could be later only because of that. -- Innocent bystander (talk) 17:40, 29 August 2017 (UTC)[reply]
You've just made me feel quite bad for not thinking about that. It shouldn't be much of a problem here though, we can have items for "northern hemisphere spring"/"northern temperate zone spring" and whatever else needed.
Also that will still be very imprecise and thoughts on the begin and end of seasons differ a lot depending on region and period. For the German middle ages and early modern period the standard work for all those questions is Zeitrechnung des deutschen Mittelalters und der Neuzeit (Q38141212), for "spring" definitions s. v. "Jahreszeiten" (German version online).
Context dependency is an argument for a more human language approach here. And eventual need for more specific terms might be an argument for a new property, against useing sourcing circumstances (P1480). --Marsupium (talk) 18:00, 29 August 2017 (UTC)[reply]
Marsupium, thanks for mentioning object named as (P1932). I did not remembered about it. --Jarekt (talk) 18:48, 29 August 2017 (UTC)[reply]

Let me add some examples:

--Jarekt (talk) 18:48, 29 August 2017 (UTC)[reply]

  • I have a problem "translating" dates found in the published sources. So I don't think "early 16th century" should be changed to "earliest date 1500-01-01"/"latest date = 1520-12-31" because we don't know what "early" means to the authority cited - is it 10 years? 25? I would prefer we add the ability to record exactly what is in a published source. - PKM (talk) 20:16, 29 August 2017 (UTC)[reply]
    Some languages can write "16th century" as "1500-talet". In my language (Swedish) I can write it in both ways. Same thing with levels in a building. Sometimes the ground level is "1" and sometimes the next level is "1". In Linköping University Hospital (Q6554447) the ground level is "9". -- Innocent bystander (talk) 05:57, 30 August 2017 (UTC)[reply]
Commons c:Module:Complex date handles translation of many date related phrases to few dozens languages, and centuries in Swedish are written using "1500-talet" notation. Translation is not an issue, the issue is how to save such phrases in Wikidata so the information so it can be retrived latter. --Jarekt (talk) 13:55, 30 August 2017 (UTC)[reply]

As a result of this discussion I am proposing New property: refine_date. Please comment. --Jarekt (talk) 16:05, 31 August 2017 (UTC)[reply]

Musical notation?

There is a specific group of items (such as melodic modes in various musical traditions) that are much better distinguished within Wikidata by having some sort of representative musical notation. While I see that Parsons code (P1236) exists, all major scale (Q190812)s would end up having "*uuuuuuu" for their ascending scales (or "*ddddddd" for their descending scales), which says nothing about the intervals between the notes that distinguish those modes from other modes. Additionally, many Indian melodic modes have differing ascending and descending scales and distinguishing motifs, as well as dominant notes, neither of which are well-representable on Wikidata. In the event a property is proposed for musical notation, should a new datatype be created for this or should the existing string datatype be used? And should any specific notation format be used in that case (abc notation maybe)? Mahir256 (talk) 20:17, 29 August 2017 (UTC)[reply]

  • This topic seems to me like one where's likey that there's prior art. How do other people do representative musical notation in knowledge databases?
Unicode provides a lot of musical symbols besides simple letters. For charts of music, moving them to Commons might be preferable. ChristianKl (talk) 21:42, 29 August 2017 (UTC)[reply]
@ChristianKl: I am not immediately aware of any musical notation scheme used in other knowledge databases. I don't think it appropriate to regenerate a musical line entirely using Unicode symbols, as there isn't a way of indicating pitch aside from flats and sharps and the like within the appropriate Unicode block (this may be better, however, for various Indian musical meters). As for the uploading of musical lines to Commons, the Score extension exists for single lines of LilyPond input; why not take advantage of that here? Mahir256 (talk) 23:02, 29 August 2017 (UTC)[reply]
Parsons code (P1236) is only suitable for a very deficient representation of melodies, definitely not for musical modes. The representation of modes by ascending scale is merely a question of convention; technically, you can arrange the tones in any order you want and add the information, which of them has some special function in the mode (reference point, tonic (Q210411), dominant, final etc.).
You could use a string in some pre-defined syntax for the pitch structure (not necessarily abc, maybe lilypond syntax provides better tools for "modes" of non-western music tradition...) or define a specific syntax for the purpose of the particular Wikidata property (something like "1 2 ♭3 4 5 6 7" or "T-s-T-T-T-T-s" as used in en.wiki). Also, you can use pictures like File:Kirchentonarten Neitram-Schema in c.jpg, File:Musical-Modes.jpg or File:PitchConstellations.svg (after extracting pictures for every particular mode needed).
IMHO, the best practice for a database project would be describing a mode through a set of statements describing the particular tones (intervals?) as "members" of the mode. I'm not sure, if has part(s) of the class (P2670) or has part(s) (P527) should be used, or maybe a specific property should be created. The special roles of some tones could be added as qualifiers or they can have separate statements.--Shlomo (talk) 10:22, 30 August 2017 (UTC)[reply]
@Shlomo, ChristianKl: Within Indian melodic modes, no note bears the role of "tonic", "subdominant", "supertonic", or the like within those modes as they do in Western melodic modes (with the exceptions of vadi (Q1923994) and samavadi (Q601825)); they are identified primarily by their Arohana (Q2011823), avarohana (Q13583589), and pakad (Q7125406) (see how all of those links were in my original comment?). As such, simply adding notes in the manner of C major scale (Q20640627) is not suitable. A predefined string pattern may well work, but it would have to be an extremely simplified form of LilyPond for a decent regex to be created for it while also maintaining compatibility with the Score extension. (On a separate note, items for solfege notes may need to be created that are distinct from notes for pitch (i.e. movable do vs C (Q843813).) Mahir256 (talk) 16:30, 30 August 2017 (UTC)[reply]

How to express the instruments often used in a music genre?

The music genre pìobaireachd (Q1457753) is overwhelmingly often performed using the instrument great Highland bagpipe (Q2164192). Similarly, rock music is often performed with bass, vocal, drums, guitar.

How can I express that on Wikidata?

Thanks! Syced (talk) 07:34, 30 August 2017 (UTC)[reply]

Maybe has characteristic (P1552)? Sjoerd de Bruin (talk) 11:17, 30 August 2017 (UTC)[reply]
⟨ great Highland bagpipe (Q2164192)  View with Reasonator View with SQID ⟩ use Search ⟨ object or value ⟩
isn't bad or even
⟨ great Highland bagpipe (Q2164192)  View with Reasonator View with SQID ⟩ genre (P136) View with SQID ⟨ object or value ⟩
d1g (talk) 04:45, 31 August 2017 (UTC)[reply]

Is it OK to import coordinates from wikipedia and how it can be done?

Wikidata:Coordinates tracking recommends importing coordinates from Wikipedia. What is the easiest way to do it? I guess that it is doable manually, but clearly it can be done easier (in extreme case by fully-automatic bot, but at least directing some tool to copy coordinates from specific articles should be available somewhere) Mateusz Konieczny (talk) 14:03, 30 August 2017 (UTC)[reply]

Pywikibot's coordinate_import.py is an example. Matěj Suchánek (talk) 18:13, 30 August 2017 (UTC)[reply]
>And try to find a Wikipedia you think is the best for your set of articles. A lot of villages in Sweden had coordinates imported from bot created articles on nlwiki, and those had very poor accuracy. -- Innocent bystander (talk) 18:49, 30 August 2017 (UTC)[reply]

Importing locations from OpenStreetMap

Has somebody already checked/discussed is it legal and desirable to import coordinates from OpenStretMap to Wikidata? Wikidata:OpenStreetMap is not mentioning anything on this topic, but Wikidata:Coordinates tracking recommends importing coordinates from Wikipedias and English Wikipedia explicitly encourages to use locations from OSM in articles (see https://en.wikipedia.org/wiki/Wikipedia:Obtaining_geographic_coordinates#OpenStreetMap).

Some discussion of situation is present at http://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia#Importing_geodata_to_Wikipedia Mateusz Konieczny (talk) 14:09, 30 August 2017 (UTC)[reply]

Ah, we are entering into a legal minefield here. OSM is licensed under the Open Database License (Q1224853) 1.0 license and you can extract or derive insubstantial portions of the OSM database without needing to relicense the extract/derivation under the same license (see the Substantial guidelines of the OSM Foundation. Take note that while you extracting 1 or a few coordinates and putting it into Wikidata is most definitely insubstantial, if too many people do the same thing and they all end up in the same database (Wikidata), it is no longer insubstantial and therefore has to be licensed under the ODbL, which violates the CC0 license of Wikidata. So, my safe answer (IANAL) is that you can't import coordinates from OSM into Wikidata. (I am both a Wikidata and OSM contributor.) —seav (talk) 03:18, 31 August 2017 (UTC)[reply]
ODbL has a simplified overview. You are free to:
  • Share: To copy, distribute and use the database.
  • Create: To produce works from the database.
  • Adapt: To modify, transform and build upon the database.
As long as you:
  • Attribute: You must attribute any public use of the database, or works produced from the database, in the manner specified in the ODbL. For any use or redistribution of the database, or works produced from it, you must make clear to others the license of the database and keep intact any notices on the original database.
  • Share-Alike: If you publicly use any adapted version of this database, or works produced from an adapted database, you must also offer that adapted database under the ODbL.
  • Keep open: If you redistribute the database, or an adapted version of it, then you may use technological measures that restrict the work (such as DRM) as long as you also redistribute a version without such measures.
Our data have no restrictions--they are CC-0 due to the particularities of databases. We don't have any restrictions on our data but OSM do, so we can't import their data en masse until one of us changes our license. (Tho, they can import our data freely.) Unfortunately, this is a really screwed-up side effect of unique database rights. If this were any other WMF project, this wouldn't be an issue. —Justin (koavf)❤T☮C☺M☯ 05:16, 31 August 2017 (UTC)[reply]
@Seav: Can I copy your explanation to Wikidata:OpenStreetMap? It would be nice to have it documented rather than hidden in discussion of project Mateusz Konieczny (talk) 07:12, 31 August 2017 (UTC)[reply]

Any wikibase:geoPrecision users?

Hi!

Is anybody around here uses or knows somebody who uses wikibase:geoPrecision value in Wikidata RDF data? I would like to hear how it is used and for what purposes. I am interested in users of specifically this data point (not coordinates in general, though if it is used together with some other values, I'd be happy to hear about it).

The background for this is that I suspect the way it is presented now is useless and should be changed. However, I do not want to start any work on it before hearing from people that might be using it (I am not sure whether such people exist, but if they do, I'd very much like to hear from them). So please respond here, or on my user page, or on wikidata list, if you know any real use cases.

Smalyshev (WMF) (talk) 20:37, 30 August 2017 (UTC)[reply]

I don't currently use it, but I assume it can be used to specify the initial zoom level for a map showing that coordinate. —seav (talk) 03:10, 31 August 2017 (UTC)[reply]
@Smalyshev (WMF): Your link is to something I do not fully understand. But our templates on svwiki uses the information in the precision parameter in the globe-coordinate datatype, but only for how the data is displayed on the screen. It is not used for such things as zoom-levels. It is rather P31/P279 that is used for that. -- Innocent bystander (talk) 05:05, 31 August 2017 (UTC)[reply]
Tracked in Phabricator
Task T89218
Tracked in Phabricator
Task T119346
I presume by "geoPrecision" you mean the third parameter of GlobeCoordinateValue as described at mw:Wikibase/DataModel#Geographic locations. This has been discussed in two Phabricator tasks, 89218 and 119346. It has also been discussed in at least two threads: Wikidata:Project chat/Archive/2015/07#Coordinates precision and mw:Talk:Wikibase/DataModel#Lack of geographic shape data type causing trouble. There seems to be no consensus about what this parameter means. Some want it to be the precision taken from the source (assuming the source expressed precision in degrees or a fraction thereof), converted to decimal degrees if necessary. Others want it to be a decimal number with one significant digit, so if the leftmost uncertain digit in an angle expressed (and stored) in decimal degrees is the hundreths digit, the precision would be 0.01. Others want the precision to correspond to the size of the thing being described, rather than the precision to which the point was measured. All this discussion has just been left hanging with no resolution for years. Jc3s5h (talk) 10:47, 31 August 2017 (UTC)[reply]
@Jc3s5h: I actually meant RDF representation of that value. As noted in discussion, having random numbers like 0.126454737464 as precisions does not seem to be very useful. So I wonder whether we can improve things there. Smalyshev (WMF) (talk) 05:43, 1 September 2017 (UTC)[reply]
Mmmmm, we have used Småorter 2005 (Q25976776) as source here, and the precision in that document is 1 meter, and how much that is in degrees depends on where you are. -- Innocent bystander (talk) 12:47, 31 August 2017 (UTC)[reply]
I can't read Swedish, so I don't know if the precision is really 1 meter, or if they simply report the raw results of their calculations to the nearest meter, without even trying to round to a number of significant digits that reflects the actual precision of the measurements. Jc3s5h (talk) 12:56, 31 August 2017 (UTC)[reply]
@Jc3s5h: The source is in SWEREF 99TM without decimals. From what I can see, that is very close to 1 meter in most places. The smallest of these entities are 100x100 meters. I have not fully understood how and why Statistics Sweden has selected to pin these exact points. It is not based on a simple mid-point in these shape-files. It is possible that they have added the distribution of the population into the calculation. -- Innocent bystander (talk) 14:17, 31 August 2017 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@ Smalyshev (WMF): you wrote "So I wonder whether we can improve things there." I think we would need to find a place to discuss this. Once a meaning is agreed to, changes would have to be made to the general data model, the JSON data model, and the RDF data model, to explain the clarified meaning. Then, changes would have to be made to the user interface to reflect the new understanding. For example, if your approach is agreed to, and a user uses the user interface to enter 73°20'13"N, 19°12'15"E and accepts the default precision of 1 arcsecond, the precision shouldn't be stored as 0.00027777777777778 as it is today, instead it should be stored as 0.0003. Jc3s5h (talk) 14:47, 1 September 2017 (UTC)[reply]

Wait a minute Jc3s5h 0.0003 is far from an arcsecond?! What is the problem with 0.00027777777777778? I think our templates on svwiki looks for a something like a precison between 0.0002777 and 0.0002778 and interpret everything there as 1/3600. -- Innocent bystander (talk) 14:59, 1 September 2017 (UTC)[reply]
I can offer arguments to support 0.0003 but I'm not willing to do so in this thread. I want a place to discuss this that has some prospect of accomplishing something before I spend time and effort finding citations and links to suitable sources. As for templates that will be broken, anybody who writes software relying on poorly written documents such as our data models is bound to get burned. We should fix the data model before even more software gets written that will later have to be rewritten. Jc3s5h (talk) 15:32, 1 September 2017 (UTC)[reply]

Gadget for Scholia

I have the Reasonator gadget activated, which puts a customised link to that tool on the left hand navigation of every item.

Please could we have a similar gadget for Scholia? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 31 August 2017 (UTC)[reply]

Do you want it to show up next to every item? Shouldn't it only show up next to items of the relevant types? I suspect that makes it a bit harder to write. − Pintoch (talk) 21:43, 31 August 2017 (UTC)[reply]
I'm content with it being on every item. I've already raised tickets on Scholia's GitHub for improving handling of "no (relevant) data" items. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:41, 1 September 2017 (UTC)[reply]
model of Wikidata-Commons links

Hello, I'm new here on Wikidata. I've opened a topic about this here, which I feel is important to discuss: Wikidata talk:Wikimedia Commons#Commons categories should link to wikipedia articles, not categories. I'm not sure if that page is much followed, as the last edits seem to be from more than 6 months ago, so I'm informing about it here as well. Please excuse me if it's not appropriate. Thank you, --DarwIn (talk) 12:24, 31 August 2017 (UTC)[reply]

There was a lot of discussions here and on Commons on how to deal with Wikidata/Commons sitelinks. We have consensus of what should link where if we have both Category and gallery on Commons and category and article item on Wikidata, See image on the right. The situation is less clear when Wikidata has only article item then it seems like the sitelink is to either category or gallery on Commons. The sitelinks are so unpredictable that are mostly unused by tools and we mostly rely on Commons category (P373) and Commons gallery (P935) properties. So as long as properties are set correctly, the sitelinks do not matter. --Jarekt (talk) 16:47, 31 August 2017 (UTC)[reply]
@Jarekt: I really do not understand why you placed Wikipedia categories in the same space as Commons categories. They share the same name on the domain, but that's all. The main working space in Wikipedia is "main", in Commons is "category" - that's what it, it has ever been like that, at least that I know of. The "main" in Commons corresponds to the galleries, which have a very residual utilization, and serve a very specific (and secondary) purpose. Linking Commons categories to articles is useful. Linking Commons categories to Wikipedia categories is pointless and doesn't serve any purpose that I can think of.--DarwIn (talk) 21:12, 31 August 2017 (UTC)[reply]
I agree with DarwIn here. The site links to articles from commons categories are quite important - they are pretty much the only way you can find the corresponding Wikipedia articles (aside from going through each image in the category to see where it is used). The way things are at the moment, with missing sitelinks, data duplication with P373 where sitelinks exist, and an absence of many interwiki links from Commons just seems weird, particularly when we already have the tools to fix this. Thanks. Mike Peel (talk) 22:07, 31 August 2017 (UTC)[reply]
@Mike Peel: That then becomes a very Wikipedia-centric approach. Many of these categories exist on the sisters so often the category to category links are important among the sisters. Tying an article to a commons category can exclude the sisters from that linking, especially if there can be only one wikilink. The hierarchical approach works more maturely for the variances that can exist.  — billinghurst sDrewth 02:34, 2 September 2017 (UTC)[reply]
There was very long RfC, that was closed in favor to item-gallery approach, but there was no consensus in fact. Both item-gallery and item-category approaches are used now on wikidata on mass scale.--Jklamo (talk) 01:53, 1 September 2017 (UTC)[reply]
It can still be corrected to article-category, as it should have been from the start. I really don't know why it was organized that way, in Commons, the old interwikis generally let to wikipedia articles, not categories. And the concept of galleries really have nothing to do with articles. An article of a museum can have a set of galleries dedicated to the exhibitions, and not a single one dedicated to the museum itself. Anyway, as far as I know, those galleries have very little use in Commons, and even less maintenance. The few that exist should never have been linked to articles in Wikidata (at least I can't see the point of doing that).--DarwIn (talk) 02:02, 1 September 2017 (UTC)[reply]
@DarwIn: Let's step back here. What you want is that Commons:Category:Haarlem links to en:Haarlem instead of to en:Category:Haarlem, right? That's a valid point. This is where it goes wrong. You assume the only way to achieve this is to move the sitelink for Commons from Category:Haarlem (Q7427769) to Haarlem (Q9920) (and messing up the data model in the process).
It should be too hard to make a (LUA) template on Commons to put on categories which generates a nice intro and also adds the interwiki links to the Wkipedia articles. No need to change anything here.
Part of the code is already available in Commons:Module:Interwiki and I added an example. In the example only missing links are added, in this case it would probably just add the links anyway. Multichill (talk) 15:46, 1 September 2017 (UTC)[reply]
@Multichill: I really do not understand the technicalities of that thing, what I see that happened is that the useful interwikis which were once in the Commons categories leading to the articles have been replaced in 2013 by useless and pointless interwikis to the wikipedia categories by Wikidata. And me, and many others, have been manually changing them to what they used to be before over those 4 years. That's how it was before Wikidata came there, and that's what apparently it should be, as the link to the wikipedia category is - again, it's never too much to repeat it - useless and pointless, as opposed to the link to the article. If the Data model has not predicted that, maybe the problem is with the model. I really do not see the point of changing the way we used to work in Commons to a new model which does not fit anyone's need, removed the useful interwikis we used to have there, and to top it added a lot of useless clutter to the right side bar. Even a link to the "commons category" is now there, as if we were not in that Commons category itself. It can't be right the way it is now.--DarwIn (talk) 15:56, 1 September 2017 (UTC)[reply]
@DarwIn: you really need to drop the attitude. The consensus has been explained to you so edits like you did on Category:Boituva (Q9558773) will just end up being reverted. I'm offering you help, but not if you continue to act like this. Multichill (talk) 16:03, 1 September 2017 (UTC)[reply]
Screenshot of Commons category Boituva after revert

@Multichill: Really, I was expecting a more constructive attitude from you than plainly reverting me. On the right, you can see what you achieved with that - Removed the useful interwikis to more than 20 wikipedia articles about Boituva in as many different languages I was working in, illustrating them while organizing the category, and replaced them with a lot of useless and pointless clutter. Reaching those articles is now much more difficult, and I'll not continue that work there - will shift for something else, as I can't easily reach them and placing the images anymore. I was hoping you were open to dialog, but I feel this is a wall here, and it's going nowhere. I think I'll just forget the whole issue. Maybe in the future I'll open a topic about this in Commons for discussion, but for now I'll just try to forget Wikidata exists, despite all the useless clutter it brings to my side bar, and the feeling that we are worst than we were before it appeared, now that we can't use the old interwikis to jump to the articles anymore. Thanks, anyway.--DarwIn (talk) 16:25, 1 September 2017 (UTC)[reply]

Don't let the door hit you on the way out. Multichill (talk) 16:52, 1 September 2017 (UTC)[reply]
Hi, TL;DR: I agree with Darwin. Regards, Yann (talk) 18:10, 1 September 2017 (UTC)[reply]
I totally agree with Darwins arguments. In addition to that I also want to point out that I have a very positive understanding on Wikidata and the people who contribute here. --Zaccarias (talk) 20:10, 1 September 2017 (UTC)[reply]
In Maarten's defense, it is in Wikidata's best interest to keep gallery (mainspace) pages linked to articles and category pages linked to category pages. We already have Commons category (P373), category's main topic (P301), and topic's main category (P910), following whom appropriate sitelinks may be found, and because gallery pages as a whole are not nearly as developed or as full as category pages on Commons, some tinkering on Commons' end is neeeded to substitute the pointless links on category pages DarwIn complains about with the appropriate mainspace links he so craves. Mahir256 (talk) 22:43, 1 September 2017 (UTC)[reply]

@Multichill: do I understand you correctly by assuming that I just need to add {{#invoke:Interwiki|interwiki}} to a Commons categories, to add the interwiki links to wp articles that were previously manually generated ? --Hsarrazin (talk) 20:14, 1 September 2017 (UTC)[reply]

@Hsarrazin: It seems to work, but looks like a patch to something broken. We'll have to add it to every existent and new category in Commons which is linked to Wikidata, in order to fix what should not be there in first place. And the pointless link to the Commons category we are already in, and some weird link to an English wikipedia category still appear in "other projects".--DarwIn (talk) 21:20, 1 September 2017 (UTC)[reply]
Multichill wrote: "It should be too hard to make a (LUA) template on Commons to put on categories which generates a nice intro and also adds the interwiki links to the Wkipedia articles. " We have template like that called c:Template:Interwiki from wikidata based on c:module:Interwiki (which should not be used directly). The setting of the sitelinks from Wikidata to Commons should be irrelevant as long as properties Commons category (P373) and Commons gallery (P935) are correctly set up. --Jarekt (talk) 01:51, 2 September 2017 (UTC)[reply]

The reality of the facts on the ground is that (contra @Multichill:) there is no consensus.

As Jklamo points out, "both item-gallery and item-category approaches are used now on wikidata on mass scale". The latest numbers that I am aware of are from January of this year, when there were 437,882 sitelinks from Commons categories to article-items here, compared to 387,768 sitelinks from Commons categories to category-items here. Four times more Commonscat links to article items compared to Commonscat links to category items were added in the 12 months previous to this, so if that trend has continued I would expect the difference now to be even greater.

In addition to what's been written above, one additional point worth considering is that in a great many cases there will not be a category-type item here to sitelink to; nor would it serve any purpose other than useless clutter to create one. In such cases, where there is no gallery on Commons and no category item here, a sitelink from Commonscat to article-item seems entirely sensible, directly achieving (and maintaining) the interwikis desired in both directions, with minimum fuss or maintenance issues.

Personally I think we should bow to what Commons users have consistently asked for, and make Commonscat to article-item links the norm (automatically giving the sitelinks most desired); with Commonscat to category-item links accepted when there is no article item. But the reality is that I would expect the current mixture to persist for the forseeable future, so software writers will need to code accordingly.

Example for Commons c:Category:Leonardo da Vinci

In the meantime, one script that I find consistently useful when looking at Commons categories is wdcat.js, which can be incorporated into one's common.js file on Commons, which displays a link (as shown on the right) whenever a Commons category is the target of a P373 from an article-type Wikidata item. Jheald (talk) 23:28, 1 September 2017 (UTC)[reply]

I agree with Jheald that in case where there is no category item than article-item -> commons-category sitelinks are fine and preferred over article-item->commons-gallery sitelinks, as majority of commons galleries were not maintained much in last decade and would be a disappointing landing spot. However in case of c:Category:Albert Einstein I prefer sitelink to Category:Albert Einstein (Q7213562) than to Albert Einstein (Q937). And if some sitelink is not to your likeing just use c:Template:Interwiki from wikidata to overwrite the defaults and add interwikis you like. --Jarekt (talk) 02:35, 2 September 2017 (UTC)[reply]
Galleries aren't useful because they miss all new content. And for selected images we have mechanisms.
Valued images sometimes miss rare topics, but they are far better than galleries.
Currently c:Category:RenderMan (software) leads to Category:RenderMan (Q8652299) and only then to RenderMan (Q855971)
I would prefer to jump between Category:RenderMan (software) and Q855971 directly. d1g (talk) 02:48, 2 September 2017 (UTC)[reply]
The existence of galleries is an issue for Commons or to be discussed at Commons. That is not for us to resolve here. If Commons use galleries, then it would seem they are needed to be fitted into place.  — billinghurst sDrewth 03:24, 2 September 2017 (UTC)[reply]
@billinghurst: The thing is, I don't believe Wikidata should be using Commons galleries at all. They were never designed or thought for a 1-on-1 correspondence as you are doing here.--DarwIn (talk) 00:14, 5 September 2017 (UTC)[reply]
That is a different conversation than the one you started, though with the same root cause "the value of galleries at Commons, and their proliferation for limited value." If all the crud galleries were swept away, the guidance expressed the whole way through applies easily. I still think that the solution needs to start at Commons, which then has Wikidata working through how to rank the relative linking, and I again restate that primary or priority linking of Commons category to Wikipedia article with an expression of there only being a direct one to one relationship is problematic.  — billinghurst sDrewth 02:14, 5 September 2017 (UTC)[reply]

Sources for being a human

There is a discussion going on Talk:Q35243900 about instance of (P31)human (Q5) and references. More input is needed, please leave your comments there. Sjoerd de Bruin (talk) 19:46, 31 August 2017 (UTC)[reply]

Opera merge

Telemaco (Telemaco (Q1393328)) is the same piece as Telemaco (Telemaco (Q3982867)) --Gerda Arendt (talk) 10:17, 1 September 2017 (UTC)[reply]

No, but Telemaco (Q30611686) and Telemaco (Q1393328) are the same. I've merged them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:30, 1 September 2017 (UTC)[reply]

Problem with Merge gadget ?

Hi, I tried to merged manganese(II) sulfate monohydrate (Q28946545) and manganese(II) sulfate monohydrate (Q27159104) but this failed. Is there a problem with the merge gadget or is there a problem with the itmes ? Snipre (talk) 00:47, 2 September 2017 (UTC)[reply]

The latter: the first one is an instance of the class represented by the second one (ie. merges to items where one links to the second one are rejected). Matěj Suchánek (talk) 08:20, 2 September 2017 (UTC)[reply]
Q27159104 now has no labels, in any language. Can someone remedy that, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:35, 2 September 2017 (UTC)[reply]
When I see the molecular formulas of both item, then it's 2 different chemical compounds. They might be related, but they aren't the same. (I restored the labels by restoring the latest version before Snipre started removing information.) Mbch331 (talk) 16:50, 2 September 2017 (UTC)[reply]
@Mbch331: perhaps it is good to study again your chemistry lectures:
Both compounds have the same molar mass, the same CAS number and the same InChIKey. For two different compounds, this is quite strange. But if you extend a little more you analysis, you will see that manganese(II) sulfate monohydrate (Q27159104) has a chemical formula which doesn't correspond to the InChI property, to the molar mass and the canonical SMILES. And finally, if you look for the real manganese sulfate, you will find manganese(II) sulfate (Q409393). So manganese(II) sulfate monohydrate (Q27159104) is a mixture of data representing manganese sulfate and manganese sulfate monohydrate, but as these two compounds have already a dedicated item, manganese(II) sulfate monohydrate (Q27159104) is a duplicate. So the merge is justified. Snipre (talk) 02:45, 3 September 2017 (UTC)[reply]

Definition of alternative ingredients in Material (P:18)

Is it possible to define in material P186 an alternative ingredients/ substitute? An example might be a table, which could be either made out of wood or metal or something different? best regards, --Scoid d (talk) 14:42, 2 September 2017 (UTC)[reply]

We need a qualifier for "typical" parts and materials from "possible" and "compatible". d1g (talk) 06:13, 3 September 2017 (UTC)[reply]
Other useful values might be "original/traditional", and "regional" (to be paired with "valid in place"). These would be very helpful for clothing and textiles which are often traditionally wool, silk, etc. but are now frequently synthetics or blends, or where different fibers are used in different places. - PKM (talk) 18:59, 4 September 2017 (UTC)[reply]

Help Trying to query Panama Papers and Citizenship or Place of Birth

I want to show a Bubble Chart. Yet I keep getting Query is Malformed: Bad Aggregate. What to do??? Please help

SELECT (COUNT(DISTINCT ?person) AS ?count) ?country_of_citizenship ?country_of_citizenshipLabel WHERE { 

 ?person wdt:P793 wd:Q23702848.
 SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
 OPTIONAL { ?person wdt:P27 ?country_of_citizenship. }

} GROUP BY ?country_of_citizenshipLabel — Preceding unsigned comment added by 2001:569:be14:200:c6d:75e7:273a:135a (talk) 17:03, 3 September 2017‎

You need to group by ?country_of_citizenship as well, since that’s also SELECTed without an aggregate function: 
SELECT (COUNT(DISTINCT ?person) AS ?count) ?country_of_citizenship ?country_of_citizenshipLabel WHERE {

 ?person wdt:P793 wd:Q23702848.
 SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
 OPTIONAL { ?person wdt:P27 ?country_of_citizenship. }

}
GROUP BY ?country_of_citizenship ?country_of_citizenshipLabel
Try it!
--TweetsFactsAndQueries (talk) 19:14, 3 September 2017 (UTC)[reply]

I mentioned before that we are collaborating with Open Library, it is part of the Internet Archive. In a major (imho) development they now link to Wikidata from their author pages. Check out Emile Zola for instance. What this indicates is the collaboration that is happening, what it enables is for us to do even more. Remember Open Library has **many** free ebooks and it is one way to get our authors and readers to read. Thanks, GerardM (talk) 05:59, 4 September 2017 (UTC) PS A big thank you to Charles Horn & Mek Karpales (at OL)[reply]

Imports Module:Wikidata

Just in case it can interest other Wikipedias, we have recently streamlined fr:Module:Wikidata. I have seen that it has already been copied in several other languages, but it is rather complex to do as it has a lot of local dependencies. The module is now a bit simpler, with 3 less submodules, and better documented. en:Module:Wikidata and en:Module:WikidataIB are almost self-contained, and as such much easier to import, but they are also much less versatile. Other versions, like cs:Modul:Wikidata and and ru:Модуль:Wikidata also appear to have interesting features and may be useful to others. --Zolo (talk) 10:33, 4 September 2017 (UTC)[reply]

Wikidata description editing in the Wikipedia Android app

Wikidata description editing is a feature being rolled out on the Wikipedia app for Android. While this primarily impacts Wikidata, the change also addresses a concern about the mobile versions of Wikipedia. Now the mobile users will be able to directly edit the descriptions shown under the title of the page and in the search results from the Wikipedia app. We began by rolling out this feature months ago to a pilot group of Wikipedias in the beginning (Russian, Hebrew, and Catalan), then to all the others, and have seen very positive results including numerous quality contributions in the form of new and updated descriptions, and a low rate of vandalism. We are now ready for the last phase of rolling out this editing feature, which is to enable it for English in a few weeks.

As always, if you have any concerns, please reach out to us on wiki at the talk page for this project or by email at reading@wikimedia.org. Thanks!

Elitre (WMF) (talk) on behalf of DBrant (WMF), 13:32, 4 September 2017 (UTC)[reply]

  • No, I mean many of them are problematic and perhaps the Android app should display something (link to the guidlines/a short version) that advices the Android app users how to create descriptions that are not problematic. --Marsupium (talk) 13:42, 5 September 2017 (UTC)[reply]

Help

The English article en:Dreadnoughts (video game) should be linked to the French article fr:Dreadnoughts (jeu vidéo, 1992) about the same game from 1992. Instead the French article is linked to the English article en:Dreadnought (video game) about a game with a similar title that was released this year! Can someone fix this please, I do not know how to do merges. 2600:1700:E820:1BA0:F547:54CF:BB57:887D 13:58, 4 September 2017 (UTC)[reply]

✓ Done --Pasleim (talk) 15:20, 4 September 2017 (UTC)[reply]

Wikidata weekly summary #276

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Other Noteworthy Stuff
    • New admin: congrats to علاء
    • Open Library, the biggest resource of freely-licensed books, now links to Wikidata (through Reasonator) and to VIAF (example here; see "Wikidata" in the right-hand column).
    • With 200 attendees, the WikidataCon is now complete. Thanks all for your enthusiasm \o/ If you registered on the waitlist or submitted a talk, check your mailbox for more information.
    • The WikidataCon program will be released this week, and we will call for volunteers soon
  • Development
    • Looked into all the things necessary to make it possible to store forms and senses on Lexeme pages.
    • Worked more on caching constraints checks results which is needed to enable constraints checks for all logged-in users (phabricator:T173696)
    • Making progress on checking constraints also on qualifiers and references (phabricator:T168532)
    • Removed language fallback hints for dialects to make the UI less cluttered for them and make it less necessary to enter labels and descriptions for them (phabricator:T174318)
    • Fixed an issue that links to an item were not showing the label when it pointed to a redirect (phabricator:T96553)
    • Unrecognized input in entity selectors will be highlighted in red (phabricator:T170531)
    • Added language code fr-ca for monolingual text input (phabricator:T151186)
    • Added an additional normalization for page titles when linking pages on Wiktionary via Cognate (phabricator:T172987)
    • The API will not only output the hashes for qualifier snaks, but also for main snaks as well as references snaks (phabricator:T174692). Note that hashes (other than IDs) are not meant to be stable identifiers, and should not be stored for a longer time.

You can see all open tickets related to Wikidata here.

Reliquaries

Reliquary with the Tooth of Saint John the Baptist (Q24946506). I have used this item as a test case with the statement: "has part -> John the Baptist -> applies to part -> tooth" but I am not convinced this is a correct way to structure this info.

I was wondering what the best way to structure statements about instances of "reliquary (Q722604)". These are, by definition "containers" of religious items - usually bone(s) or of saints, pieces of hair, splinters of wood or nails... We currently have 1900 Wikidata items responding to the query of "instance of -> reliquary" with the vast majority of those being bot-imported items from the French database of movable cultural heritage with a Palissy ID (P481). For example, this reliquaire de crâne de saint Victurnien is Q29247401.
A few dozen of these items have Wikipedia articles in some languages, however as far as I can see (though I admit I have not looked at ALL of them) none has any statements pertaining to their "contents". That is: how should a Wikidata item about a reliquary state what is inside it?
has part(s) (P527) and made from material (P186) both are suggested properties for the word "contains" but neither is appropriate in my opinion. Equally, I feel applies to part, aspect, or form (P518) (or some equivalent?) must be used in some manner in order to indicate specificity - e.g. not the whole saint, but just a finger bone etc. I have used "has part" with a qualifier of "has part" in the test-case item described in the image to the right.
Does anyone have any suggestions? The solution needs to be sufficiently flexible to accommodate individual specific bones and/or mummified pieces of specific people; entire mummified bodies or skeletons (e.g. Karlsschrein (Q1551658); non-human objects (such as 'piece of wood' or 'nail' from the True Cross (Q380356)).
One of the interesting potential use-cases of this kind of work would be to "discover" a saint with >10 fingers, or to map the native habitat of the various types of wood claimed to be pieces of the true cross... Wittylama (talk) 15:49, 4 September 2017 (UTC)[reply]

Crazy idea, I love it!
And good question: I agree that made from material (P186) clearly doesn't seems appropriate (if the reliquary is made of gold, the origin of the gold is often unknown and doesn't matter but for the relic itself, it matter greatly where it come from) ; has part(s) (P527) is a little better but I'm not sure... For it to work, we would need an item about the relic itself (eg. 'tooth of John the Baptist'), don't we?
PS: I can't wait to see how many tons of relic of the True Cross (Q380356) there is in the world!
Cdlt, VIGNERON (talk) 16:19, 4 September 2017 (UTC)[reply]
VIGNERON - you don't need a wikidata item for the individual part being described (e.g. "tooth of john the baptist") IF you use the "applies to part" qualifier - see the example in the caption of the image above. That at least solves the need to have a wikidata item for every bone of every saint but I don't think it solves the overarching question. Wittylama (talk) 16:39, 4 September 2017 (UTC)[reply]
An alternative to "has part -> John the Baptist -> applies to part -> tooth" might be "has part -> tooth -> of -> John the Baptist" --Pharos (talk) 17:05, 4 September 2017 (UTC)[reply]
Yes great idea and I also think "has part <the person in question>" and then "applies to part <the part in question>" is an elegant approach. Jane023 (talk) 18:37, 4 September 2017 (UTC)[reply]
One concern I have is that the "applies to part" qualifier usually indicates which part of the subject of the statement it is that the statement applies to -- so <painting> "made of": "wood" has the qualifier "applies to part": "frame".
Part of the cleanup planned for the qualifier P794 (P794) is to separate usages which qualify the subject of the statement from usages which qualify the object, and to use different properties for each. It would be a shame, just as this is being dealt with, to create a similar muddle with "applies to part". Jheald (talk) 21:03, 4 September 2017 (UTC)[reply]
Ah, Jheald you mean to say that in my example Use-case, by using the "applies to part" qualifier the "tooth" is technically being implied to be a part of the Reliquary/container not the saint?
Do you have a solution? I feel like there must be one :-) Surely there must be other circumstances where we need to structure the concept of "X is 'inside of' Y"? I am loath to suggest "a new bespoke property" just for religious containers! Wittylama (talk) 21:45, 4 September 2017 (UTC)[reply]
In principle it should be easy enough to create a property that would be parallel to applies to part, aspect, or form (P518), but would indicate a part of the value of the statement, rather than a part of the subject. I am sure that reliquaries can't be the only case where that could be useful! The real challenge is to think up a good name for it, that would be natural but distinguish it from P518. "Applies to part (of value):" might do as a first stab; but it might be a bit opaque and mysterious to somebody coming across it for the first time in a statement on a page. Jheald (talk) 22:51, 4 September 2017 (UTC)[reply]
I think that this sense of "contains" should be different from P527 and P186
We also had physically interacts with (P129) and designed to carry (P3349)
But not a property for "used as container for" "contains"
Container item is here: physical container (Q987767) d1g (talk) 07:47, 5 September 2017 (UTC)[reply]
Q29478647 (like distribution format (P437), host (P2975), has natural reservoir (P1605))? --Fractaler (talk) 13:10, 5 September 2017 (UTC)[reply]

Help needed converting Ordinance Survey National Grid references to coordinates for Wikidata import

Hi all

I'm helping import a list of British castles into Wikidata here, unfortunately the spreadsheet we have does no provide normal coordinates, only Survey National Grid references. My question is how do we convert these? We have over 1000 sites so manually will not be possible, here is a direct link to the spreadsheet if anyone knows how to do the conversions.

Thanks

--John Cummings (talk) 21:42, 4 September 2017 (UTC)[reply]

@John Cummings: Looks like there is a batch converter here that may let you paste in a column of grid references.
Alternatively there are certainly library subroutines in Python or Perl for this, that could be used as the basis for a script.
Note that we should probably have items with coordinates already for almost all of these, from previous imports of listed buildings / ancient monuments. But I'm sure it's well worth also having the coordinates from the spreadsheet if possible, to sanity check the possible matches. Jheald (talk) 22:30, 4 September 2017 (UTC)[reply]
Hi @Jheald:, thanks very much fr your help, luckily the online converter worked perfectly :) Thanks again, --John Cummings (talk) 07:36, 5 September 2017 (UTC)[reply]

Liangent-bot

Should bots be clearing items in order to add a link? [2]

If this kind of editing is permitted, then how do we check whether or not information was lost? The diff shows all data removed with the edit, and no matches. --EncycloPetey (talk) 02:30, 5 September 2017 (UTC)[reply]

@Liangent: ^^ --Liuxinyu970226 (talk) 05:00, 5 September 2017 (UTC)[reply]

How to connect parent (Q7566) and offspring (Q239526) etc. and others?

User:Paweł Ziemian User:Jura1 (is this project family relationships?) User:Infovarius User:Melderick User:Bvatant

Notified participants of WikiProject Parenthood and others below.

There'd be some use of kinship item labels and properties for i18n on Commons, it would be fine to know there is a consensus on some scheme and it's stable. Thus some questions:

  1. Should parent (Q7566) and offspring (Q239526) etc. be connected with opposite of (P461)? Like parent (Q7566)opposite of (P461)offspring (Q239526) and offspring (Q239526)opposite of (P461)parent (Q7566)?
  2. Should this also be done for items with a gender between those of same gender? Like grandson (Q11921506)opposite of (P461)grandfather (Q9238344)? (E.g. used by Tomáš Páv, 2016-01.) With qualifier criterion used (P1013): Inverse function (Q191884)? (E.g. used by علاء الدين‎, 2016-08-22.) (BTW: Would raise single-value constraint (Q19474404) either way.)
  3. Should brother (Q10861465) and sister (Q595094) etc. be connected with opposite of (P461)? Like brother (Q10861465)opposite of (P461)sister (Q595094)? (Consensus?: e.g. used by 桂鷺淵, 2015-09, removed by Zolo, 2015-10-07, used again by Infovarius, 2015-10-09.)
  4. Should there be a qualifier with criterion used (P1013)?
    1. With gender binary (Q5530970) as value? Like brother (Q10861465)opposite of (P461)sister (Q595094)criterion used (P1013)gender binary (Q5530970)? (E.g. used by Robin van der Vliet, 2016-08-24.)
    2. Or with biological sex (Q290) as value? (E.g. used by علاء الدين‎, 2016-08-22.)
  5. stepfather (Q1282201)part of (P361)stepparent (Q19822352) should be deleted I guess?

Thank you, --Marsupium (talk) 09:09, 5 September 2017 (UTC)[reply]

If you like to make use of family relationship properties for specific persons, you should use "child" (Property:P40), "mother", "father", "sibling", "spouse", etc. If none of these applies or can't be directly derived from these (e.g. grandfather/grandmother), then use "relative". Relative would have a qualifier "kinship type" whose item value would have label that describes the relationship. This relationship should match the one found in the source of that statement. .. at least ideally.
--- Jura 09:42, 5 September 2017 (UTC)[reply]
Those are general questions and arise also independently of the reuse on Commons. But if I want to process the Wikidata statement Pieter Pourbus (Q981558)child (P40)Frans Pourbus the Elder (Q1445472) to an i18n version of "father of Frans Pourbus the Elder", I need to get from "child" to "father" somehow. I could use inverse property (P1696) here, but I can't do that any more for relative (P1038) and kinship to subject (P1039). --Marsupium (talk) 10:55, 5 September 2017 (UTC)[reply]
parent (Q7566)opposite of (P461)offspring (Q239526) and offspring (Q239526)opposite of (P461)parent (Q7566) (criterion used (P1013)causality (Q179289)) --Fractaler (talk) 11:01, 5 September 2017 (UTC)[reply]
To me grand parent feels more like the opposite of grand-child than brother the opposite of sister, but actually we could more accurately describe it as the date of official opening (P1619) (maybe we should have the equivalent of this property, but with item datatype ?).
I am not really clear how we could make use of this property in commons:Template:Kinship. I would think we have to hardcode every relationship like: if if (grand-parent and female) then label = grandmother end--Zolo (talk) 12:16, 5 September 2017 (UTC)[reply]
You then have to remember that we in some languages (like sv) do not have a word for "grandmother". We have one for "grandmother on the mothers side": "mormor" and another for "grandmother on the fathers side": "farmor". We have the same problem with "aunt", "uncle", "niece" etc. -- Innocent bystander (talk) 12:35, 5 September 2017 (UTC)[reply]

Same?

Pierre Viala (Q21611695) and Pierre Viala (Q1448769)? --Magnus Manske (talk) 13:43, 5 September 2017 (UTC)[reply]

Yes, Pierre Viala (Q21611695)'s National Library of Greece ID (P3348) link says "owl:sameAs http://viaf.org/viaf/77099628" which matches Pierre Viala (Q1448769)'s VIAF ID (P214) Syced (talk) 14:10, 5 September 2017 (UTC)[reply]

Wikidata Missing Pictures (offline)

Traveling without Internet?

Still want to know what nearby Wikidata objects need an image (P18)?

Download this KMZ into your GPS app!

Open source generator, developers welcome :-) Syced (talk) 14:05, 5 September 2017 (UTC)[reply]

New notification on wikis when a page is connected to Wikidata

Hello all,

For your information, during the last months, we deployed a new notification type on the Wikimedia projects where the sitelinks are provided by Wikidata. When an editor creates a new page (Wikipedia article, Wikivoyage page, etc.) and this page is connected later to a Wikidata item, the creator of the page now receives a notification to inform him about that, with a message like “The page X has been connected to a Wikidata item” and a link to this item.

This will hopefully help people to be more aware of Wikidata and the support we provide to the other projects. This feature will be disable by default for existing editors, and enabled by default for new editors.

The deployment is now complete on all the Wikimedia wikis. Lea Lacroix (WMDE) (talk) 14:11, 5 September 2017 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=552232398"