Module talk:WikidataIB

This is an old revision of this page, as edited by Jheald (talk | contribs) at 09:37, 20 February 2017 (getQualifierValue only works for properties that are Q-number valued ?). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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}}<
  1. ><
  2. >Fred Bloggs<
  3. >George Orwell  <
  4. >Freda Bloggs<
  5. ><

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}}<
  1. >George Orwell  <
  2. >George Orwell  <
  3. >Retro Hugo Award for Best Novella  <
  4. >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  <
  5. >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}}<
  1. >George Orwell  <
  2. >George Orwell  <
  3. >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)Reply

@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 / 31.9583; -111.5967
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)Reply

Format Dates

Some test cases for the function formatDate. Call like {{#invoke:WikidataIB |formatDate | 1 August 30 BCE |bc=BCE |df=dmy}}

Input date: 1 August 30 BCE, 12:39:56
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
Input date: 20 January 2017, 12:39:56
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}}

Input date: 1 August 30 BCE, 12:39:56
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
Input date: 20 January 2017, 12:39:56
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:

Can't get this working

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)Reply

@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)Reply
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)Reply

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)Reply

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)Reply
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)Reply

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)Reply

(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)Reply
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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply

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)Reply

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)Reply

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:

Jackie Chan (Q36970)

{{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)Reply

@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 and suppressfields 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 and suppressfields. 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)Reply

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? Thanks. Jheald (talk) 09:35, 20 February 2017 (UTC)Reply