Module talk:WikidataIB
Testing
Let's see how this would work in Animal farm, d:Q1396889.
Local parameter
# >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50 |Fred Bloggs}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50 |fetchwikidata=author; number_of_pages |name=author}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50 |fetchwikidata=author; number_of_pages; |name=author |Freda Bloggs}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50 |fetchwikidata=author; number_of_pages |name=author |suppressfields=author}}<
- ><
- >Fred Bloggs<
- >George Orwell <
- >Freda Bloggs<
- ><
Only sourced
# >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50 |fetchwikidata=ALL |name=author |onlysourced=no}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50 |fetchwikidata=ALL |name=author |onlysourced=yes}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P166 |fetchwikidata=ALL |name=awards |onlysourced=}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P166 |fetchwikidata=ALL |name=awards |onlysourced=no}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P166 |fetchwikidata=ALL |name=awards |onlysourced=yes}}<
- >George Orwell <
- >George Orwell <
- >Retro Hugo Award for Best Novella <
- >Retro Hugo Award for Best Novella, Modern Library's 100 Best Novels, NPR Top 100 Science Fiction and Fantasy Books, Prometheus Award - Hall of Fame <
- >Retro Hugo Award for Best Novella <
No icon
# >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50 |fetchwikidata=ALL |name=author |noicon=}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50 |fetchwikidata=ALL |name=author |noicon=no}}< # >{{#invoke:WikidataIB |getValue |qid=Q1396889 |P50 |fetchwikidata=ALL |name=author |noicon=yes}}<
- >George Orwell <
- >George Orwell <
- >George Orwell<
Coordinates
Just to note that it would be nice to be able to set the coordinates to display both inline and in the title (passing "|display=inline,title" to {{coord}}); this module just seems to allow inline coordinates. Thanks. Mike Peel (talk) 17:37, 18 December 2016 (UTC)
- @Mike: I've implemented the 'display' parameter now. This is how it would work in Kitt Peak National Observatory (Q592248):
{{#invoke:WikidataIB |getCoords |qid=Q592248 |name=coord |fetchwikidata=ALL}}
→ 31°57′30″N 111°35′48″W / 31.9583°N 111.5967°W
- You should see 31°57′30″N 111°35′48″W in the title position of this page as well.
- You can't see multiple examples because the of title coordinates.
- If you want to test the "title" or "inline" values, change the above to
{{#invoke:WikidataIB |getCoords |qid=Q592248 |display=title |name=coord |fetchwikidata=ALL}}
{{#invoke:WikidataIB |getCoords |qid=Q592248 |display=inline |name=coord |fetchwikidata=ALL}}
- Of course, you don't need this so much now that the coord templates are Wikidata-aware, but it's useful if you want to implement the white/blacklists. --RexxS (talk) 11:55, 16 January 2017 (UTC)
Format Dates
Some test cases for the function formatDate. Call like {{#invoke:WikidataIB |formatDate | 1 August 30 BCE |bc=BCE |df=dmy}}
no parameters | 1 August 30 BCE |
bc=BC | 1 August 30 BC |
bc=BCE | 1 August 30 BCE |
bc=bc | 1 August 30 BC |
bc=bce | 1 August 30 BCE |
bc=XYZ | 1 August 30 BCE |
df=dmy | 1 August 30 BCE |
df=DMY | 1 August 30 BCE |
df=mdy | August 1, 30 BCE |
df=MDY | August 1, 30 BCE |
df=ABC | 1 August 30 BCE |
df=y | 30 BCE |
bc=BCE df=dmy | 1 August 30 BCE |
bc=BCE df=mdy | 1 August 30 BCE |
bc=BCE df=y | 30 BCE |
bc=BC df=dmy | 1 August 30 BC |
bc=BC df=mdy | August 1, 30 BC |
bc=BC df=y | 30 BC |
no parameters | 20 January 2017 |
bc=BC | 20 January 2017 |
bc=BCE | 20 January 2017 |
bc=bc | 20 January 2017 |
bc=bce | 20 January 2017 |
bc=XYZ | 20 January 2017 |
df=dmy | 20 January 2017 |
df=DMY | 20 January 2017 |
df=mdy | January 20, 2017 |
df=MDY | January 20, 2017 |
df=ABC | 20 January 2017 |
df=y | 2017 |
bc=BCE df=dmy | 20 January 2017 |
bc=BCE df=mdy | 20 January 2017 |
bc=BCE df=y | 2017 |
bc=BC df=dmy | 20 January 2017 |
bc=BC df=mdy | January 20, 2017 |
bc=BC df=y | 2017 |
Some test cases for the function formatDate. Call like {{#invoke:WikidataIB/sandbox |formatDate | 1 August 30 BCE |bc=BCE |df=dmy}}
no parameters | 1 August 30 BCE |
bc=BC | 1 August 30 BC |
bc=BCE | 1 August 30 BCE |
bc=bc | 1 August 30 BC |
bc=bce | 1 August 30 BCE |
bc=XYZ | 1 August 30 BCE |
df=dmy | 1 August 30 BCE |
df=DMY | 1 August 30 BCE |
df=mdy | August 1, 30 BCE |
df=MDY | August 1, 30 BCE |
df=ABC | 1 August 30 BCE |
df=y | 30 BCE |
bc=BCE df=dmy | 1 August 30 BCE |
bc=BCE df=mdy | 1 August 30 BCE |
bc=BCE df=y | 30 BCE |
bc=BC df=dmy | 1 August 30 BC |
bc=BC df=mdy | August 1, 30 BC |
bc=BC df=y | 30 BC |
no parameters | 20 January 2017 |
bc=BC | 20 January 2017 |
bc=BCE | 20 January 2017 |
bc=bc | 20 January 2017 |
bc=bce | 20 January 2017 |
bc=XYZ | 20 January 2017 |
df=dmy | 20 January 2017 |
df=DMY | 20 January 2017 |
df=mdy | January 20, 2017 |
df=MDY | January 20, 2017 |
df=ABC | 20 January 2017 |
df=y | 2017 |
bc=BCE df=dmy | 20 January 2017 |
bc=BCE df=mdy | 20 January 2017 |
bc=BCE df=y | 2017 |
bc=BC df=dmy | 20 January 2017 |
bc=BC df=mdy | January 20, 2017 |
bc=BC df=y | 2017 |
Calls to getValue for dates
Some calls to getValue that return dates:
- In Marcus Antonius Creticus (Q357585):
{{#invoke:WikidataIB |getValue |qid=Q357585 |P569 |fetchwikidata=ALL}}
-> - In Mark Antony (Q51673):
{{#invoke:WikidataIB |getValue |qid=Q51673 |P569 |fetchwikidata=ALL}}
-> 83 BC - In Mark Antony (Q51673):
{{#invoke:WikidataIB |getValue |qid=Q51673 |P569 |fetchwikidata=ALL |bc=BC}}
-> 83 BC - In Mark Antony (Q51673):
{{#invoke:WikidataIB |getValue |qid=Q51673 |P569 |fetchwikidata=ALL |df=mdy}}
-> 83 BC - In Mark Antony (Q51673):
{{#invoke:WikidataIB |getValue |qid=Q51673 |P569 |fetchwikidata=ALL |df=y}}
-> 83 BC - In Richard Burton (Q151973):
{{#invoke:WikidataIB |getValue |qid=Q151973 |P569 |fetchwikidata=ALL}}
-> 10 November 1925 - In Richard Burton (Q151973):
{{#invoke:WikidataIB |getValue |qid=Q151973 |P569 |fetchwikidata=ALL |bc=BC}}
-> 10 November 1925 - In Richard Burton (Q151973):
{{#invoke:WikidataIB |getValue |qid=Q151973 |P569 |fetchwikidata=ALL |df=mdy}}
-> November 10, 1925 - In Richard Burton (Q151973):
{{#invoke:WikidataIB |getValue |qid=Q151973 |P569 |fetchwikidata=ALL |df=y}}
-> 1925
Can't get this working
- manufacturer (P176) (see uses)
About en:Prussian P 10, item: Prussian P 10 (Q882458). It has P176=Borsig (Company). So Wikidata seems OK.
In this case I test:
-{{#invoke:WikidataIB|getValue|qid=Q882458|P176}}-
Returns empty string: --
Also, when previewing in article page itself (no |qid=
used), it returns a blank. Am I missing something? -DePiep (talk) 17:32, 15 January 2017 (UTC)
- @DePiep: Remember that this is designed for use in an infobox, therefore there are extra parameters that have to be enabled otherwise it won't return anything. The call matches the name of the field you're using it in with a list of fields that are to enabled ("whitelisted"). What you call the field doesn't matter as long as it's on the whitelist. So you can use:
{{#invoke:WikidataIB |getValue |qid=Q882458 |P176 |name=def |fetchwikidata=abd, def, ghi, jkl, etc}}
→
- And it will return manufacturer (P176) for Prussian P 10 (Q882458). I'll miss out the qid in the first part of the following examples as you won't need it other than for testing on pages like this.
- Rather than having to list every fieldname on the whitelist, you can use "ALL". So the call you probably want is something like:
{{#invoke:WikidataIB |getValue |P176 |name=manufacturer |fetchwikidata=ALL}}
→
- Although if you're designing an infobox, you'll probably want to pass the whitelist (and blacklist) as parameters so the article editor supplies them once and the infobox passes them to each call in the design. Lets say we give them the names
|whitelist=
and|blacklist=
. Then the code in the infobox design for the 'Manufacturer' field would be:{{#invoke:WikidataIB |getValue |P176 |name=manufacturer |fetchwikidata={{{whitelist|}}} |suppressfields={{{blacklist|}}} |{{{manufacturer|}}} }}
- The second unnamed parameter allows a local parameter (called 'manufacturer' in this case) to override the Wikidata call as ususal.
- The infobox in use in an article could look something as simple as:
{{infobox something | whitelist = ALL }}
- Does that make sense? Let me know if you're still having problems. Cheers --RexxS (talk) 02:03, 16 January 2017 (UTC)
- Thanks, will process this. Could this be in the documentation? Sort of basic "required parameters" list? To me, the description & examples there are already quite abstract (into high end usage). Quite an object that requires studying. -DePiep (talk) 09:16, 16 January 2017 (UTC)
Date handling
If more extensive date handling is ever needed, consider Module:Date which can parse dates in various formats, including a Wikidata date, and perform date arithmetic. However, the module is limited to four-digit years. The template {{extract}} can be used for quick tests although it does not expose options to choose the BC/BCE format.
{{extract|+2016-06-21T14:30:00Z}}
→ 14:30 21 June 2016{{extract|+2016-06-21T14:30:00Z|show=ymd}}
→ 14:30 2016-06-21
Johnuniq (talk) 23:41, 20 January 2017 (UTC)
- Thanks John. I think I had most of that functionality, as well as the BC/BCE and dmy/mdy/y functionality in Module:Wikidata in the getDateValue function, which dealt with any date BC or AD - I needed that for dob of notable Romans, etc. although the code was hard to read because I was using the timestamp and manipulating that directly. For greater flexibility in this module, I decided to use the mw.wikibase.formatPropertyValues() function – which always returns dmy format dates with BCE as appropriate – because that can be used on properties that are qualifiers as well. I'll need that later as fewer properties are defined and more values are stored as properties of qualifiers (like property:creator - qualifier:has role - item:video game artist instead of property:video game artist). Things like marriages have start-date and end-date that are in qualifiers. Anyway, I think I've managed to create a local function that takes the date in dmy+BCE format and outputs it in whatever format is wanted for use in article infoboxes. I've put a wrapper around it so that it's exported and can be invoked. --RexxS (talk) 04:00, 21 January 2017 (UTC)
- Good, and I'm sure Wikidata has many quirks which require dedicated code. I just wanted to say that if more stuff such as date differences or adding time deltas were ever needed, Module:Date is available. Johnuniq (talk) 05:59, 21 January 2017 (UTC)
Bug in fetching referenced data
At Edward Bergh I added a second date at d:Q5572078 with year-only accuracy, as that's what I can easily find a reference for atm. Now that there's a reference, it displays the date in the infobox. However, it fetches the *unreferenced* date (with day-accuracy) rather than the referenced one (with year-accuracy). Not a big deal, since changing the rank causes the correct one to show, but this is probably an edge-case that should be fixed (@RexxS). Thanks. Mike Peel (talk) 16:35, 28 January 2017 (UTC)
- (Note: I've found a ref for the day-accuracy one, so I've now removed the year-accuracy one from the entry, but this can be found in the history. Thanks. Mike Peel (talk) 16:39, 28 January 2017 (UTC)
- Thanks, Mike. I'll have a think about how best to solve this issue. I originally thought that allowing date format to be set to "y" in the article would be enough, but sometimes there are two different date fields displayed with different precisions. It would be a shame to have to import the hugely complex date parsing code from Module:Wikidata that works from the raw timestamp just to ensure that we can respect the precision set by an referenced date. In many ways, the rank system at Wikidata is the "proper" solution – because a referenced date is always going to be preferred to an unreferenced one, and it makes that clear to other users of the Wikidata – but I know that we'd all prefer not to have to do that manually. Maybe a bot could be run on Wikidata which changed the rankings of unsourced statements to be lower than those of sourced ones? Can you see any downside in that? --RexxS (talk) 18:17, 28 January 2017 (UTC)
- I think this is just a question of how the code should select which value to use, rather than having to affect the date formatting code. This could easily happen with a plain-text/Q-linked value as with a date. I haven't figured out the details of the ranking system on Wikidata myself yet - I'm not sure whether you can have more than one "preferred rank" value or not. Thanks. Mike Peel (talk) 18:30, 28 January 2017 (UTC)
- @Mike: As far as I know, you can have many of each rank as you wish. The question is how should we deal with the case where multiple values of the property exist with the same rank? We would want to return as a list multiple values of most fields, e.g. occupation, but surely we wouldn't want multiple dates of birth returned? --RexxS (talk) 20:56, 28 January 2017 (UTC)
- Apparently sometimes multiple dates of birth do need to be returned, e.g. from d:Q885424. So maybe just return all of the referenced statements for the highest rank available? Thanks. Mike Peel (talk) 22:52, 6 February 2017 (UTC)
- I'd prefer to use a local parameter for such a case. We could then have "3 or 9 August 1858", rather than the list that the call would naturally return: "3 August 1858, 9 August 1858". That's because the call doesn't know that we would write the list of dates in the former way for disputed dates of birth. I could certainly make the list output with "or" separating the dates, but shorthand styles like "3 or 9 August 1858" and "30 July or 9 August 1858" are a lot more work to program, and hence more room for errors and edge cases, and I'd want to see a lot more testing in sandbox if we went down that route. --RexxS (talk) 04:34, 7 February 2017 (UTC)
- Apparently sometimes multiple dates of birth do need to be returned, e.g. from d:Q885424. So maybe just return all of the referenced statements for the highest rank available? Thanks. Mike Peel (talk) 22:52, 6 February 2017 (UTC)
- @Mike: As far as I know, you can have many of each rank as you wish. The question is how should we deal with the case where multiple values of the property exist with the same rank? We would want to return as a list multiple values of most fields, e.g. occupation, but surely we wouldn't want multiple dates of birth returned? --RexxS (talk) 20:56, 28 January 2017 (UTC)
- I think this is just a question of how the code should select which value to use, rather than having to affect the date formatting code. This could easily happen with a plain-text/Q-linked value as with a date. I haven't figured out the details of the ranking system on Wikidata myself yet - I'm not sure whether you can have more than one "preferred rank" value or not. Thanks. Mike Peel (talk) 18:30, 28 January 2017 (UTC)
- Thanks, Mike. I'll have a think about how best to solve this issue. I originally thought that allowing date format to be set to "y" in the article would be enough, but sometimes there are two different date fields displayed with different precisions. It would be a shame to have to import the hugely complex date parsing code from Module:Wikidata that works from the raw timestamp just to ensure that we can respect the precision set by an referenced date. In many ways, the rank system at Wikidata is the "proper" solution – because a referenced date is always going to be preferred to an unreferenced one, and it makes that clear to other users of the Wikidata – but I know that we'd all prefer not to have to do that manually. Maybe a bot could be run on Wikidata which changed the rankings of unsourced statements to be lower than those of sourced ones? Can you see any downside in that? --RexxS (talk) 18:17, 28 January 2017 (UTC)
Unsafe use of labels
Code like this:
local label = mw.wikibase.label("Q" .. v.mainsnak.datavalue.value["numeric-id"])
if label == nil then label = "Q" .. v.mainsnak.datavalue.value["numeric-id"] end
if sitelink then
out[#out + 1] = "[[" .. sitelink .. "|" .. label .. "]]"
or like this:
local label = mw.wikibase.label(valueID)
if not label then label = valueID end
if sitelink then
out[#out + 1] = "[[" .. sitelink .. "|" .. label .. "]]"
is not safe. Labels may contain any characters including [|]{} so a label could be constructed to generate e.g. any internal or external links. I suggest that you add mw.text.nowiki(label) before using labels in wikitext. The same applies to any string and text values from Wikidata. Best regards, Dipsacus fullonum (talk) 07:15, 3 February 2017 (UTC)
- That's interesting. As it is clearly necessary to apply the mw.text.nowiki() function to every call to mw.wikibase.label() (without exception for the reasons given), it makes you wonder why the nowiki function is not applied to the mw.wikibase.label() internally. --RexxS (talk) 20:23, 5 February 2017 (UTC)
Alternative field names
Template:Contains Chinese text
Hi, I'm from Chinese Wikipedia. How can I give an alternative name to a field? Because the Chinese language has multiple writing systems (traditional + simplified), each parameter usually both has a traditional and simplified (and sometimes, English) name. How to make the fetchwikidata
or suppressfields
field work when a traditional or simplified name of a parameter is filled in? Such as:
{{Infobox entertainer/WD <!-- English Wikipedia does not have this template, but this template is available on Chinese Wikipedia. It is called {{藝人/WD}} --> | fetchwikidata = 出生地点 | name = Jackie Chan | type = Actor }}
or
{{Infobox entertainer/WD <!-- English Wikipedia does not have this template, but this template is available on Chinese Wikipedia. It is called {{藝人/WD}} --> | fetchwikidata = 出生地點 | name = Jackie Chan | type = Actor }}
or
{{Infobox entertainer/WD <!-- English Wikipedia does not have this template, but this template is available on Chinese Wikipedia. It is called {{藝人/WD}} --> | fetchwikidata = birth_place | name = Jackie Chan | type = Actor }}
These will fetch place of birth from Wikidata. But now I can only use one of them to do that. --Dabao qian (talk) 16:24, 5 February 2017 (UTC)
- @Dabao qian: I'm not sure I understand all that happens on Chinese Wikipedia when multiple labels are available. Nevertheless, I'll try to explain as much of WikidataIB as I can. Both
fetchwikidata
andsuppressfields
work by looking for the label/name of the field that is passed in the invocation, within the string that is passed by the article to|fetchwikidata=
and|suppressfields=
. So if the template defines 'Birth place' as something like{{#invoke:WikidataIB |getValue |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced={{{onlysourced|}}} |noicon={{{noicon|}}} }}
, then|fetchwikidata=birth_place, birth_date, death_place, death_date
(for example) would match the"|name=birth_place"
in the infobox definition, and the call would return place of birth (P19). Using|fetchwikidata=ALL
in an article would return all properties that are invoked in the infobox definition. - I think that you can avoid the multiple labels by deciding on using just one style of field name and documenting it, so that editors use just the string you specify in the list of fields passed to
fetchwikidata
andsuppressfields
. If you use"|name=birth_place"
in the infobox definition, then editors have to use"|fetchwikidata=abc, def, ..., birth_place, ..., xyz"
. - I've just realised that your two examples you have 出生地點 ("Birth place") and 出生地点 (also "Birth place"). Does that mean you want to use both of those in your infoboxes? If so, then make two invocations in the infobox definition, one with
|name=出生地點
and the other with|name=出生地点
. Then use|fetchwikidata =abc, ..., 出生地點 出生地点, ..., xyz
and both will be displayed, if that's what you want. - Please ping me again if I've not answered your query with something useful, and let me know if I can be more specific. Cheers --RexxS (talk) 19:32, 5 February 2017 (UTC)
getQualifierValue only works for properties that are Q-number valued ?
It seems getQualifierValue only works for properties that are Q-number valued.
Is there a good reason for this? I had been hoping to use it to extract a qualifier from a property that is external-identifier valued, for example:
{{#invoke:WikidataIB |getQualifierValue |P1367 |pval=simpson-charles-walter-18851971 |qual=P1114 |fetchwikidata=ALL |qid=Q5083334 }}
- ->
to extract the number of works at Art UK associated with Charles Walter Simpson (English artist) (Charles Walter Simpson (Q5083334)).
Also, is it possible to omit the value for pval=
in cases where there is only one pval, since my template is not currently written to handle cases when there is more than one anyway? Thanks. Jheald (talk) 09:35, 20 February 2017 (UTC)
- @Jheald: Indeed, I only wrote the function getQualifierValue to deal with properties that are wikibase-entities because I knew that infoboxes will normally only be dealing with those sort of values for qualifiers (because of the multi-lingual nature of Wikidata). If somebody comes up with an exception, I can handle that with extra code, but as this module is specifically intended for use in creating infobox templates, I was lazy.
- Now, in your case, handling of external identifiers for use in different templates is worth making a separate module for, as we don't need any of the black/white-listing and source-filtering facilities of WikidataIB. So I've made Module:WikidataIdentifiers to hold functions related to that. Try previewing
{{#invoke:WikidataIdentifiers |getIdentifierQualifier |P1367 |qual=P1114}}
in Charles Walter Simpson (English artist) and you should get 27 (unless somebody changes it in Wikidata). If you want to use it outside of his article, then the expansive call is available:{{#invoke:WikidataIdentifiers |getIdentifierQualifier |P1367 |qual=P1114 |qid=Q5083334}}
→
- The function assumes that there is only one value for the property Art UK artist ID (P1367) – list of exceptions are at d:Wikidata:Database reports/Constraint violations/P1367 #Single_value – and that the value has only one qualifier which is a quantity. I can expand the code to cater for other types of qualifiers, but you'd have to tell me what other types you anticipated. Naturally, the #invoke can be wrapped in a template to sweeten the syntax for others. Hope that does the trick for you. Cheers --RexxS (talk) 15:39, 21 February 2017 (UTC)
- I feel I've now been given a fantastic early birthday present, all wrapped up in a bow!
- {{Art UK bio}} is now starting to update across 750 transclusions, with a potential further 6,500 ready to add.
- I sent an email to Art UK on Friday with the list of potential duplicates from Wikidata (all of which seem pretty plausible); but no response from them as yet.
- Thank you again for such-appreciated Lua magic, and very best regards, Jheald (talk)
- Would it also be possible to have a routine that pulls source properties, in particular P813 "retrieved" ? (And perhaps a pretty date formatter?) I should perhaps be including that information when the external id is being cited as a ref. Jheald (talk) 19:27, 22 February 2017 (UTC)