Template talk:Authority control/Archive 7

From WikiProjectMed
Jump to navigation Jump to search
Archive 1 ← Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10

Should NLA and GND links be edited to reduce redirects and eliminate HTTPS->HTTP redirects?

As of now, it appears that NLA links generate two redirects, one of which involves accessing an HTTP URL. For instance, the URL https://nla.gov.au/anbd.aut-an35118769 generates a 302 Moved Temporarily redirect to http://librariesaustralia.nla.gov.au/search/display?dbid=auth&id=35118769 which generates a 301 Moved Permanently redirect to https://librariesaustralia.nla.gov.au/search/display?dbid=auth&id=35118769. Would it be useful to edit the template module to generate NLA links of the form https://librariesaustralia.nla.gov.au/search/display?dbid=auth&id= instead of the current form https://nla.gov.au/anbd.aut-an? This change might reduce the number of redirects and also provide increased privacy and security for users by eliminating the redirect to an HTTP URL.

For GND links, there appears to be a similar situation, but with three redirects. For instance, the URL https://d-nb.info/gnd/1032307897 generates a 303 See Other redirect to http://d-nb.info/gnd/1032307897/about/html which generates a 301 redirect to https://d-nb.info/gnd/1032307897/about/html which generates a 302 redirect to https://portal.dnb.de/opac.htm?method=simpleSearch&cqlMode=true&query=nid%3D1032307897. Would it be useful to edit the template module to generate GND links of the form https://d-nb.info/gnd/XXXXXXXXX/about/html instead of the current form https://d-nb.info/gnd/XXXXXXXXX (where XXXXXXXXX is the identifier for the specific work)?

--Elegie (talk) 09:23, 14 April 2018 (UTC)

Yes, that looks desirable Maybe not; see next comment.. I checked that the same redirects occur here, and they do. See my sandbox (permalink) for a test case with the URLs that are generated. That might be useful for checking whether more links should be updated. Johnuniq (talk) 10:52, 14 April 2018 (UTC)
On second thoughts, it is conceivable that a certain form of the URL could be "guaranteed" to always work because the website will redirect that URL to the current location of the data, similar to the idea of a digital object identifier. If the template is tweaked to use the redirect rather than the recommended link, the result may break if the website changes the URL of the ultimate data. We need someone familiar with the various authority control procedures. Johnuniq (talk) 23:30, 14 April 2018 (UTC)
At the current time, I have template editor rights. At the same time, on the issue of whether the NLA and GND links should be adjusted, my thought was that it would be useful to get input from others before going ahead and making changes. In particular, if a link references URL A which generates a 301 Moved Permanently redirect to URL B, then it seems safe to edit the link to use URL B instead of URL A. At the same time, if a link references URL A which generates a 303 See Other redirect or a 302 Moved Temporarily redirect to URL B, then it is less certain that URL B will be supported in the future. --Elegie (talk) 06:57, 17 April 2018 (UTC)
Further input would be good. Meanwhile I captured the first set of responses from each of the URLs in my sandbox sample mentioned above. If some changes occur, these might need to be included.
Johnuniq (talk) 07:56, 17 April 2018 (UTC)

"Lua error in Module:Authority_control at line 397: Tried to read nil global createRow."

Hi, I just want to report the above error, which I noticed at the bottom of the page Zerah Colburn (mental calculator) (though it also seems to be occurring on this page itself as well). Opencooper (talk) 19:22, 11 May 2018 (UTC)

Same error also at the bottom of Benjamin Lay. wbm1058 (talk) 19:42, 11 May 2018 (UTC)
A null edit seems to have made it go away? wbm1058 (talk) 19:45, 11 May 2018 (UTC)
@Reedy: ? I see you've been making changes to Module:Authority control. wbm1058 (talk) 19:48, 11 May 2018 (UTC)

@Reedy: The refactoring was apparently to implement Module:Authority control painting for {{Authority control painting}}. It might have been better to add a parameter to {{Authority control}} to insert the extra identifiers wanted for paintings. Modifying the main module is now significantly complicated by the fact that just about everything is exported, so any change might impact something that uses the export. Also, the duplication currently seen at the bottom of The Night Watch would be avoided if there was just one template. Johnuniq (talk) 23:52, 11 May 2018 (UTC)

It was done for User:Jane023, who has struggled to get anyone to help her get the things she wanted onto painting pages. Technically, it doesn't even need a parameter. Just adding mapping/searching/formatting for the field would've been enough, and it's existence then on the Wikidata item would make it appear. The whole usage is confusing. As is the "ordering" of the authority items. It seems to be in some sort of vague suggestion of "importance", and/or order added. Not deterministic, such as alphabetical. It vaguely makes out that it's for "Biography" things, but if you look at usages, it's used elsewhere (such as cities). This needs fixing/clarifying. The module isn't any more complicated. What do you mean by "so any change might impact something that uses the export"? Reedy (talk) 08:21, 12 May 2018 (UTC)
Suppose the module needed to be refactored for some feature or to cope with some change. The person doing that work would need to understand the effect their changes would have on the module and make sure nothing would break. In addition, because nearly everything is exported, the person should study "what links here" and examine how the exported functions and data are used elsewhere to make sure nothing in them would break. That is much more difficult than just changing one module, particularly given how useless "what links here" is for this sort of use. Johnuniq (talk) 09:18, 12 May 2018 (UTC)
Isn't that always the case. Testing where possible, checking for more usages? The painting version just overrides `conf` and adds some extra url formatters needed for the different authority control. I'm happy to merge the painting version back into this one (well, the module), and then I think we should alphasort the data sources, rather than the current version which is indeterministic? Reedy (talk) 09:22, 12 May 2018 (UTC)
I have worked on this module but I never understood some of the details, such as why things were ordered as they are. I always like alpha order. Also, I think I found some dead code (never called) which was very confusing. Is there any reason for {{Authority control painting}} to be separate? If not, I would suggest starting again and just adding the new identifiers here. If they are not wanted for some articles, we can handle that later, but I don't see why an article would want to suppress an identifier if it were defined in Wikidata (except for the unusual #Two authority controls on a page? above). Johnuniq (talk) 09:39, 12 May 2018 (UTC)
Jane and I were thinking something very similar. We couldn't work out why it's all done manually, and there's multiple more identifiers on Wikidata. We should just look up ALL identifiers on Wikidata, and use that to build the urls, do the validation etc. The data is on Wikidata. No point reinventing the wheel. It might make tracking categories a little harder (unless we can map 1:1, not a big deal either way), but that's not major.
I've put the additionals from the other Module into this one, and am just replacing the templates (And cleaning up any doubles in the mean time). Reedy (talk) 09:45, 12 May 2018 (UTC)
There have been multiple suggestions for similar authority control bar schemes (right now I can think of Template:Taxonbar). Mostly it's just down to someone implementing it. --Izno (talk) 13:19, 12 May 2018 (UTC)
The order it is currently in is roughly by count of data items at the authority control source in question/importance and/or size of to authority control generally. --Izno (talk) 13:19, 12 May 2018 (UTC)

I quite agree that the earlier version where not everything was exported (and most functions were local) was much better. There are several problems with this module that are mostly related to history and effort to fix. I have always wanted to refactor this into using format as a regular expression (P1793) and formatter URL (P1630) (you can see where left a comment to that effect in the code once). This would remove the need for most the URL generating functions and the maintenance associated with such. This was originally not done in such a way for a few reasons including copying for code from the old javascript and the fact that the Scribunto Wikidata client interface made it expensive to look up Wikidata entity statements for any entities other than the one linked to the current article (this is still somewhat true but has been relaxed somewhat). The other major refactor that could use to be done has to do with tracking catergories. Module:Check for unknown parameters in its current state is not really designed to be used as a Lua module but really only supports being called from a template (due to its frame handling). This module could be refactored to pull all claims and keep them as well as passed arguments and then major choices based on both of these making it able to handle category tracking naturally (instead the round about way it is shimmed in now). 2600:1700:EDB0:A060:14D0:1D18:969:4211 (talk) 12:21, 16 May 2018 (UTC)

MusicBrainz at ELN

Whether or not MusicBrainz authority file numbers should be included in {{authority control}} is currently discussed at Wikipedia:External links/Noticeboard#MusicBrainz. Please discuss there, not here. --Francis Schonken (talk) 16:20, 20 May 2018 (UTC)

NARA ID

The US National Archives Identifier property in Wikidata has changed since it was added to this template. The template currently uses "NARA-organization", P1223 and "NARA-person", P1222. However, now there is a single National Archives Identifier for all authority types (and no need for different URL structures), and it is now P1225. The URL structure is now "https://catalog.archives.gov/id/<id>". Can the template code be updated? Thanks! Dominic·t 17:39, 24 May 2018 (UTC)

 Done.   ~ Tom.Reding (talk ⋅dgaf)  18:17, 24 May 2018 (UTC)
So I wrote a module to automatically create its own documentation table of parameters used from the conf table to remove the busywork of maintaining consistent documentation, but Module:Authority control/doc/Wikidata properties table first needs to be made to recognize Lua. The working code is in that module's history, which I've undone. Reedy (the creator and only editor of that module) or Xaosflux (whom I think I've seen perform this change elsewhere), can one of y'all help?   ~ Tom.Reding (talk ⋅dgaf)  19:11, 24 May 2018 (UTC)
I can process an edit request if it is demonstrated to work in a sandbox, but I don't normally write those myself. — xaosflux Talk 19:14, 24 May 2018 (UTC)
Per my posts above, the recent changes should be wound back because making everything global causes trouble in the long term. The function to create the documentation table (here) should be incorporated into the main module and invoked on the documentation page. I have done similar in a couple of modules and it works well, particularly since having all the code in one place means that if a relevant change is made, the documentation code is more likely to be fixed. Johnuniq (talk) 23:32, 24 May 2018 (UTC)
Content model will need changing back if you turn it back into a Lua module. Reedy (talk) 11:35, 25 May 2018 (UTC)
Self-generating wikitable is now part of the main module,impatience is a virtue? so no need to change anything (thanks for the good suggestion Johnuniq). Module:Authority control/doc/Wikidata properties table can remain as-is for posterity or TfD'd.   ~ Tom.Reding (talk ⋅dgaf)  16:12, 25 May 2018 (UTC)

Bot request to place template on all biographies

FYI @ Wikipedia:Bots/Requests for approval/Tom.Bot 6 just submitted, pending discussion/approval.   ~ Tom.Reding (talk ⋅dgaf)  14:54, 4 May 2018 (UTC)

@Tom.Reding: Just a heads up, there is an ongoing discussion at WP:ELN#Authority_control regarding your bot adding {{authority_control}} to articles and potentially causing policy infringements. — AfroThundr (t•c) 05:43, 29 May 2018 (UTC)
Umm, there is no policy involved. Johnuniq (talk) 06:00, 29 May 2018 (UTC)
I'm only referring to the edits cited in the linked section. Apparently they believe tagging articles with {{authority_control}} is synonymous with WP:LINKFARM (since the template is only populated with an MBID at the moment), and also using WP:RSN#WikiData_Source as a rationale to remove them. It seems to me that if MBIDs weren't supposed to be used in articles, we wouldn't have a whole set of templates dedicated to tagging articles with them. What do y'all think about this? Should the bot tag articles when it would only be adding "minor" identifiers like MBIDs? — AfroThundr (t•c) 06:51, 29 May 2018 (UTC)
AfroThundr, thank you, I saw. Was busy with Memorial Day festivities here in the US.
Regarding the WP:LINKFARM issue, which I don't think applies, anyone interested should voice their concerns/opinions there for centralized discussion.   ~ Tom.Reding (talk ⋅dgaf)  13:48, 29 May 2018 (UTC)

Should IDs without a reference and/or imported from Wikipedia be hidden?

Option 1: IDs without a Wikidata reference should be hidden by default.
Option 1a: IDs without a Wikidata reference and a 'retrieved on' date should be hidden by default.
Option 2: IDs with an 'imported from <lang> Wikipedia' reference should be hidden by default.
Option 3: both Option 1/a (specify) & Option 2.
Option 4: neither Option 1/a nor Option 2 (no change).

I'm in favor of at least Option 2, as this is self-referential. From my mild anecdotal evidence only, IDs without a reference are usually added to Wikidata by mediocre/inexperienced bots, so I'd like to hear others' opinions on the matter.   ~ Tom.Reding (talk ⋅dgaf)  15:28, 29 May 2018 (UTC)

Added Option 1a for a bit more constraint after initial feedback.   ~ Tom.Reding (talk ⋅dgaf)  21:26, 29 May 2018 (UTC)

  • Option 2 At the least, maybe Option 1. I would also propose we implement the ability to suppress a specific ID with an empty |param=, like we can with infoboxes. That would probably appease a lot of people who have issues with the automatic inclusion. — AfroThundr (t•c) 15:39, 29 May 2018 (UTC)
  • Option 4 - they are self-referencing. Thanks. Mike Peel (talk) 15:42, 29 May 2018 (UTC)
Mike Peel, shouldn't they at least reference the associated database, i.e. MusicBrainz artist ID @ The Motet (Q18393471)?   ~ Tom.Reding (talk ⋅dgaf)  18:26, 29 May 2018 (UTC)
The properties link to the relevant database, of course. He means the citation on the WikiData property is listed as "Imported from Wikipedia" with no actual reference. — AfroThundr (t•c) 18:58, 29 May 2018 (UTC)
No. The reference for VIAF 22325780 is VIAF 22325780. Just display the ID and the link, and job done. Mike Peel (talk) 19:10, 29 May 2018 (UTC)
I would prefer to see some proper reference at Wikidata is what I mean, so I added Option 1a for a bit more constraint.   ~ Tom.Reding (talk ⋅dgaf)  21:26, 29 May 2018 (UTC)
  • option 4, per Mike Peel. This is however not the problem. —Dirk Beetstra T C 03:30, 30 May 2018 (UTC)

General discussion - importing IDs without reference

This is all besides the point. You see whether the data is correct or not because of the link it provides. But since there is, barring rare exceptions, NO reason to ever change an identifier, they should be individually protected. WikiData does not allow for that, en.wikipedia does not allow for it (though it could be done through protected templates). This is the whole problem, the whole referencing story is a red herring. —Dirk Beetstra T C 03:30, 30 May 2018 (UTC)

Adding Wikidata item link to aid navigation

Is there support for adding a link to the page's Wikidata item at the start of the nav bar, similar to Template:Taxonbar#More taxon examples, in the form of "Wd: Q12345"? I think this would help alleviate some complaints about accessibility/fixing discrepancies that are exposed/imported from Wikidata, by making navigation faster/easier. This would especially help on long articles where the normal 'Wikidata item' link is at the top of the page.   ~ Tom.Reding (talk ⋅dgaf)  14:20, 26 May 2018 (UTC)

This is how {{authority control}} at Elsie Janis would look (Wikidata is the first item):
It's more bloat but it would be useful, so yes, I think it's good. Johnuniq (talk) 00:43, 27 May 2018 (UTC)
No, no, no! Adding another wiki, another source of unreliable information, to this already bloated, overloaded, and hardly useful (for most readers) template makes it worse, not better. Instead, you could better improve Help:Authority control (linked from the template directly) to indicate where the information comes from and how to improve (or remove) it. That page now doesn't even mention Wikidata, which is strange. Fram (talk) 12:13, 27 May 2018 (UTC)
That's quite a self-defeating argument since this proposal will help make said unreliable information more reliable by making it easier for/more obvious to editors how to correct/add/remove information. Also, this isn't a discussion on whether or not AC is useful. Finally, will read over Help:AC (admittedly I haven't).   ~ Tom.Reding (talk ⋅dgaf)  15:20, 27 May 2018 (UTC)
Speaking of self-defeating arguments, adding an external link which we first need to make reliable is not really useful or wanted. It would then be much more logical to simply keep the few useful identifiers on enwiki, which would diminish the need to maintain two sites to get these identifiers right, and would make it easier to just display the wanted ones per article, not a one-size-fits-all like we have now and which gets less useful every time something is added to this template. Fram (talk) 06:35, 28 May 2018 (UTC)
Incorrect; I've corrected your premise: It would then be much more logical to simply keep the few useful identifiers on enwiki, which would decrease increase the need to maintain two sites to get these identifiers right.   ~ Tom.Reding (talk ⋅dgaf)  13:45, 28 May 2018 (UTC)
Nope. For the sake of enwiki, we would only need to keep one site correct (enwiki), instead of two (enwiki and Wikidata). Furthermore, we would only need to check the few identifiers actually needed per article (e.g. no Swedish database for non-Sweden-related subjects), not everything Wikidata can lay their hands on. We (enwiki) would have no need to make Wikidata correct, so there would be no need for us to maintain two sites. Fram (talk) 14:18, 28 May 2018 (UTC)
Then I suggest you start a discussion to revert AC back to its template form.   ~ Tom.Reding (talk ⋅dgaf)  14:48, 28 May 2018 (UTC)

More about {{authority control}} links causing problems at WP:ELN#Authority control. --Francis Schonken (talk) 14:40, 28 May 2018 (UTC)

  •  Comment: This is already implemented on other wikis (but with a different style). I don't think it harms anything, although it is a duplication of the link shown in the sandbar. Thanks. Mike Peel (talk) 22:13, 28 May 2018 (UTC)
  1. ACQexample

I'd keep the Q number on the left (it represents the authority file of the combined WikiMedia projects: it is WikiMedia's "own", in that sense different from systems that are external to this group of projects):

I already proposed something in that vein last year, see Template talk:Authority control/Archive 6#Suggestion for the left cell of the authority control template.

Anyhow, displaying a link to WikiMedia's own authority file thus prominently may make it easier when it comes to deciding that we maybe need a few less external authority file links directly in Wikipedia: such additional/specialised ones are easy to reach via the Q number link (see discussions elsewhere as linked above). --Francis Schonken (talk) 23:20, 28 May 2018 (UTC)

This looks like a good solution to me. I'd suggest displaying 'Wikidata' in place of the Q-number and wrapping the link with <small>. The MusicBrainz link discussion is a distraction with this topic and should be considered separately. Thanks. Mike Peel (talk) 00:14, 29 May 2018 (UTC)
Re. "'Wikidata' in place of the Q-number": disagree – every article already has a linked "Wikidata item" in the left margin going to exactly the same place, this one should be different. I'd rather have an unlinked (Q2144892) than a linked (Wikidata). (Q2144892), as proposed, works for me too, although this would need broad enough support (displaying the same link twice on the same page).
Re. "<small>" – I'd un-bold it (didn't know how to with the divs in the example), but going to small doesn't seem necessary imho. The number needs to be clearly legible.
Re. "distraction" – would keep the discussion elsewhere (as indicated), was just indicating that that other discussion may become a bit easier as a consequence of this. --Francis Schonken (talk) 06:59, 29 May 2018 (UTC)
I like this solution too, primarily because it makes the Q# link more obvious. One possible issue might be that this will make most (I think, based on my observations) AC templates 2 lines high instead of 1. The vast majority of my AC placements have been on pages with <= 5 IDs/elements, and Category:AC with 14 elements and above total to only ~2500 out of the ~660k+ transclusions. It would be good to know how many there are above, say ~5-7, but I don't know how to do this without creating another tracking category. This might be doable via a Wikidata query, but I'll have to play around with it first (if anyone knows/can, please do so!).
For this proposal, a second link to the Q# is absolutely necessary to aid navigation, while a general Wd link is 'gravy'. Many Q#'s are quite long so adding 'Wikidata item' or even 'Wikidata' I don't think would be aesthetically desirable. I'm fine with 'Wd:' though, but a non-bold Q2144892 seems to be the front-runner (which should be possible, but I can't confirm nor deny it now).   ~ Tom.Reding (talk ⋅dgaf)  15:11, 29 May 2018 (UTC)
Given that we're moving towards some curtailment of parameters in the discussions below, further reducing the # of multi-line ACs, the in-line (RHS) option now seems better than the LHS option.   ~ Tom.Reding (talk ⋅dgaf)  23:48, 3 June 2018 (UTC)
  • After reading this proposal again, I oppose. WD is linked in the toolbox, and that is enough. WikiData is NOT an authority on any subject, and it is a unreliable source. It should not be linked from content (in extreme cases it would even be in multiple boxes). WikiData, as an external link, fails our inclusion standards. —Dirk Beetstra T C 04:18, 4 June 2018 (UTC)
Do you also oppose {{commons category}}, {{wikiquote}}, {{wikisource author}}, {{wikispecies}}, etc., which we regularly add to external links, which also appear in the sidebar?   ~ Tom.Reding (talk ⋅dgaf)  10:36, 4 June 2018 (UTC)
So you did not read why I reason that WD should not be in {{authority control}}. And those templates are another question. --Dirk Beetstra T C 11:31, 4 June 2018 (UTC)
Commons, wikispecies, etc., aren't reliable sources, and they appear in the sidebar and external links. What else am I missing from your argument?   ~ Tom.Reding (talk ⋅dgaf)  11:47, 4 June 2018 (UTC)
WikiData is NOT an authority on any subject .. ... it does not belong in the {{authority control}}. This is not a discussion about the duplication of Commons, WikiQuote, WikiSource, or WikiSpecies. We could very well have a box {{wikidata}} that displays as {{wikiquote}} .. but that is not the template that we are discussing here. And yes, to a large extend I do think that those boxes are other crap that is largely not content that we should include - the boxes are often standard include, even if all the images from commons are already used in the article. And even if not, I think that those boxes are indeed also obsolete as they are, as you mention, already in the toolbox. We are not writing a linkfarm. For the rest, most of the data linked INSIDE the authority control box is an authority for the identifier. If they are not, they are not supposed to be there. And if they are not reliable I would argue that their use is to be deprecated, as the authority that precipitated this whole discussion. --Dirk Beetstra T C 12:35, 4 June 2018 (UTC)
Ahh, I see, thank you for being more clear. So "(Q12345)" on the LHS would then be ok, because it's not contained within the list of authorities.   ~ Tom.Reding (talk ⋅dgaf)  13:12, 4 June 2018 (UTC)
still part of authority control, right .. no. If I just said that I think that half of the AC should not be linked/mentioned (let alone blanket oncluded, see other discussions on AC), and that I indeed think that often to sisterlinks are 'other crap' .. why do you think that I would agree with a blanket inclusion of WD ID. No, that is not OK either. --Dirk Beetstra T C 14:35, 4 June 2018 (UTC)
So it appears that you just don't like it - I'm trying to extract something useful from your argument, but have failed.   ~ Tom.Reding (talk ⋅dgaf)  15:03, 4 June 2018 (UTC)
I am trying to extract something useful from WikiData, but I cannot. A WD ID does not standard belong on authority control. It should be a specific choice when it specifically adds something (like we link to a commns cat when it in the opinion adds something). Not a blanket ‘we always link when there is authority control’. Some thing useful from my argument? All I get from WikiDataians is ‘we offer the same crap as you have, so why not transclude crap instead of using your own. In that way all wikis have the same crap.’. Can we finally show how this IMPROVES en.wikipedia. You’ve now got two opposes. Time for an RfC for this practice, to see if the wider community wants to continue? —Dirk Beetstra T C 16:00, 4 June 2018 (UTC)
Neither oppose has been meaningful.   ~ Tom.Reding (talk ⋅dgaf)  16:33, 4 June 2018 (UTC)
@Tom.Reding: I'd suggest turning this bit into an RfC or post it on WP:VP to get a few more opinions in here. I like having the link, but Beetstra raises valid concerns that may be shared by others around here. Might as well see how the rest of the community feels. Assuming we can keep it limited in scope and on track. — AfroThundr (u · t · c) 16:44, 4 June 2018 (UTC)
  1. Yes, it will likely run off-scope;
  2. I don't see any valid concerns that haven't been/can't be addressed by putting "(Q12345)" in the LHS (see first two sections of testcases for working examples);
  3. but I'll assume I'm mistaken.
  ~ Tom.Reding (talk ⋅dgaf)  17:31, 4 June 2018 (UTC)
Tom, you really think that linking on every single page that has authority control to WD ID while that link is in the toolbox is the same as a thoughtful linking to the e.g. commons category by adding the resp. Template there. If you are linkinng on all pages to the WD ID through the AC template, theyou can as well add ALL possible AC identifiers to the template, as well as the commons cat, wikisource, species and wiktionary - I am square against doing that.
I am looking forward to the RfC. I was already considering one as well. —Dirk Beetstra T C 17:44, 4 June 2018 (UTC)
We do that on {{Taxonbar}}, unless it's dormant, and it's quite helpful.   ~ Tom.Reding (talk ⋅dgaf)  19:10, 4 June 2018 (UTC)
Ah. Strong argument</sarcasm>. I am getting quite fed up with ‘look there’ arguments. Why is it helpful HERE. What do I gain from going to WD from AC (over toolbox). Go draft an RfC and lets sehow helpful the community at large thinks it is. —Dirk Beetstra T C 19:16, 4 June 2018 (UTC)
Please read the original post.   ~ Tom.Reding (talk ⋅dgaf)  19:23, 4 June 2018 (UTC)
And another look there. What is the advantage ON EVERY ARTICLE to link it in authority control. —Dirk Beetstra T C 03:19, 5 June 2018 (UTC)
Relevant to th other crap here: I did this yesterday. —Dirk Beetstra T C 00:05, 7 June 2018 (UTC)
That wasn't helpful, but the link's now in the sidebar anyway (it wasn't there when you made your edit). Mike Peel (talk) 00:59, 7 June 2018 (UTC)
How did you add it there .. not that that is of importance to this discussion, as WikiData is ALWAYS there. —Dirk Beetstra T C 03:50, 7 June 2018 (UTC)
Found it. Sigh, more stuff that we don’t have control over on en.wiki. Anyway, whereever it is, at the moment that link does not lead to more info. When that changes .... —Dirk Beetstra T C 03:55, 7 June 2018 (UTC)


Now at Village Pump (proposals)

Add IAAF ID

Hi, I was hoping to add World Athletics athlete ID (P1146) to the authority control template. If they're OK, I can add the changes to all the non-protected pages after (and if) this edit request is approved. Here are all the changes I think need to be made:

Extended content

Add to Module:Authority control: 

p.conf = {
   -- ...
   { 'HDS', '[[Historical Dictionary of Switzerland|HDS]]', 902, p.hlsLink },
   { 'IAAF', '[[International Association of Athletics Federations|IAAF]]', 1146, p.iaafLink },
   { 'ISNI', '[[International Standard Name Identifier|ISNI]]', 213, p.isniLink },
   -- ...
}

-- ...

function p.iaafLink( id )
    if not string.match( id, '^%d+$' ) then
        return false
    end
    return '[https://www.iaaf.org/athletes/biographies/athcode=' .. id .. ' ' .. id .. ']'
end

Add to Module:Authority control/doc: 

{{Uses Wikidata|<!--...-->p1146<!--...-->}}

<!-- ... -->

=== By identifier ===

<!-- ... --->

[[International Association of Athletics Federations|IAAF]]:
* {{clc|Wikipedia articles with IAAF identifiers}}
* {{clc|User pages with IAAF identifiers}}
* {{clc|Miscellaneous pages with IAAF identifiers}}

Add to Template:Authority control/doc: 

; Full : <kbd>{{Authority control |<!--...-->IAAF=xxxxxx<!--...-->}}</kbd>

; Blank : <kbd>{{Authority control |<!--...-->IAAF= <!--...-->}}</kbd>

<!-- ... -->

{| class="wikitable sortable"
! Parameter || Scope || Name || Search || Remarks
<!-- ... -->
|-
| IAAF
| People
| [[International Association of Athletics Federations]]
| [https://www.iaaf.org/athletes]
| The IAAF athlete database lists information about [[sport of athletics]] competitors.
<!-- ... -->
|}

Create category pages with the following contents: 

Category:Wikipedia articles with IAAF identifiers
{{catmore|Wikipedia:Authority control}}
{{Wikipedia category|hidden=yes|tracking=yes}}
[[Category:Pages with IAAF identifiers]]
[[Category:Wikipedia articles with authority control information|IAAF]]

Category:User pages with IAAF identifiers
{{possibly empty category}}
{{catmore|Wikipedia:Authority control}}
{{Wikipedia category|hidden=yes|tracking=yes}}
[[Category:Pages with IAAF identifiers]]
[[Category:User pages with authority control information|IAAF]]

Category:Miscellaneous pages with IAAF identifiers
{{possibly empty category}}
{{catmore|Wikipedia:Authority control}}
{{Wikipedia category|hidden=yes|tracking=yes}}
[[Category:Pages with IAAF identifiers]]
[[Category:Miscellaneous pages with authority control information|IAAF]]

Category:Pages with IAAF identifiers
{{catmore|Wikipedia:Authority control}}
{{Wikipedia category}}
[[Category:Pages with authority control information|IAAF]]

This database might be slightly different than the rest added but I think it's suitable for inclusion as an authoritative and internationally recognized source on athletes. Note that while there is already {{IAAF name}}, I think that template serves a different purpose, generally either used as a reference to source statements (in which case it should be kept) or as an external link (in which case using this template would be better).

Let me know if there are any changed to this ER you'd like to see implemented and I would probably be OK with that too.

Thanks, --Habst (talk) 18:10, 6 June 2018 (UTC)

No comments, positive or negative about this proposal. I intend to make the change shortly. @Habst: please make necessary changes to Module:Authority control/sandbox. You can edit the documentation pages and create the categories yourself once the change has been made. Cheers — Martin (MSGJ · talk) 07:39, 13 June 2018 (UTC)
Hi @MSGJ, thanks! I made the changes to Module:Authority control/sandbox and can make the doc / category changes as soon as the edit goes live. --Habst (talk) 07:45, 13 June 2018 (UTC)
 Done — Martin (MSGJ · talk) 15:48, 13 June 2018 (UTC)

Module:Authority control/doc/Wikidata properties table

@Tom.Reding: could the four category count values (article, user, misc, fautly) bei integrated into the table Module:Authority control/doc/Wikidata properties table? Best by Lua programming? And the values could be labels of links going to the categories. 2.245.10.35 (talk) 11:14, 17 June 2018 (UTC)

Yes, merging Module:Authority control#Parameter names and associated Wikidata properties & Module:Authority control#Tracking categories seems like a good idea. I might run into the 'expensive function call limit', but we'll see (I just tested 44 x 4 = 176 {{clc}} calls and got no warnings). If I had to remove a column to save on function calls, I'd probably remove the 'user' type cats. Either way, the more complete table should/will also be placed at Template:Authority control#Wikidata, which is currently desynced from the Module:Authority control#Parameter names and associated Wikidata properties.   ~ Tom.Reding (talk ⋅dgaf)  14:13, 17 June 2018 (UTC)
Tom.Reding, thanks a lot. Instead of clc, one could directly use {{PAGESINCATEGORY:Wikipedia articles with ISNI identifiers}}, not? 2.245.10.35 (talk) 15:14, 17 June 2018 (UTC)
 Done! This also prompted a long-overdue ID-tracking cat update, cat-checking improvements, and cat standardization.   ~ Tom.Reding (talk ⋅dgaf)  16:56, 19 June 2018 (UTC)

Poll: Russian State Library RSL/RLS parameter typo solution

There is no "RLS" acronym on Russian State Library on Wikipedia nor RSL ID (person) (P947) on Wikidata, and "RSL" is their official website www.rsl.ru, so the question now is: should we have a short "aliases" table in the module to seamlessly sort out issues like this, or simply clean up existing cases and pretend it never happened?

The tracking categories for this and a number of other params were never implemented, which I'm about to do. They'll start to be populated shortly to get a better sense of the scale of the issue, but it will take some time for the ~700k pages to pass through the work queue.   ~ Tom.Reding (talk ⋅dgaf)  14:25, 19 June 2018 (UTC)

On further inspection, I think a p.aliases{ ... } table is probably the best of those 2 solutions, since I already see cases for a few more:
  1. PND -> GND (exists)
  2. RLS -> RSL (proposed)
  3. MusicBrainz -> MBA (precautionary)
  4. Leonore -> Léonore (for ease of input)
Plus, it'd be constructed similar to p.conf so that a relatively inexperienced, but intelligent TE could add new entries themselves, as opposed to the current state, which isn't as straightforward.   ~ Tom.Reding (talk ⋅dgaf)  20:13, 19 June 2018 (UTC)

Add LNB & NSK IDs?

I noticed National Library of Latvia ID (P1368) & NSK ID (P1375) are mentioned in the doc but are not yet implemented. The only mention of them in the template archives are in this 1 comment 3 years ago by T.seppelt. LNB has ~21,000 uses on WD, and NSK has ~3000. Is there any desire to add them? If not, their mention and already-existing cats should probably be removed.   ~ Tom.Reding (talk ⋅dgaf)  13:23, 21 June 2018 (UTC)

~All 21,000 LNB instances would be added to en.wiki, and ~all NSK instances. I think I've yet again answered my own question...   ~ Tom.Reding (talk ⋅dgaf)  13:28, 21 June 2018 (UTC)

The time allocated for running scripts has expired

@Tom.Reding: I don't have time at the moment to review the many improvements to Module:Authority control, but something is causing a problem at Friedrich Dürrenmatt. Editing that page and replacing it with {{Authority control}} then previewing gives a timeout error message. Johnuniq (talk) 07:22, 25 June 2018 (UTC)

Oh that is brilliant .. that means that we are limited in how much checking of WD parameters we can do. —Dirk Beetstra T C 07:26, 25 June 2018 (UTC)

Investigation shows that the problem is the complex regex in tlsLink(id). For the problematic article, the id is "Friedrich_Dürrenmatt" and the "ü" causes the regex to explode. It is probably a bug in the underlying Lua because I ran a stand-along Lua 5.1 program and had to terminate it after 30 seconds of runtime. The result is instantaneous when id is changed to replace "ü" with "u". If the Lua bug did not exist, the regex would fail because "ü" will not satisfy the pattern. It is better to avoid use of mw.ustring.match which is much slower than Lua's string.match, but in this case the former works well so I edited the module to use it. Sorry but I also trimmed trailing whitespace. I have no idea whether the regex will work with all cases—it seems unlikely that it would. Johnuniq (talk) 10:31, 25 June 2018 (UTC)

Thank you Johnuniq. Based on this, the only other new string.match function I found that might preemptively benefit from ustring is p.botanistLink, since it uses \p{Lu}\p{Ll} on the WD side and %u%l on the WP side. p.lccnLink -> p.splitLccn could be satisfied with [a-z], but it just uses %l for shorthand, so no need for ustring there. I'll edit p.botanistLink shortly. Will look into into what's going on with KULTURNAV first though.   ~ Tom.Reding (talk ⋅dgaf)  13:07, 25 June 2018 (UTC)

Suppressing local display via null parameters

Original suppression proposal

Per suggestions by AfroThundr3007730 above, and Finnusertop and Nikkimaria at WP:ELN, but opposed by Beetstra there, I think it's good to have a separate dedicated discussion about this to gauge consensus. Cleanup-wise, AC migrated away from local parameters 5 years ago now, so there's probably very little cleanup that would have to be done prior to this. I'll start running a scan for empty AC params and see what kind of #s I come up with.   ~ Tom.Reding (talk ⋅dgaf)  22:10, 29 May 2018 (UTC)

Empty param scan: ~175,000 transclusions scanned, and only 2 found with empty params, both redirects. Extrapolating, this puts the estimated total # of transclusions with null params ~10, so very safe to do. Will also implement a tracking cat for suppressed params if this goes through.   ~ Tom.Reding (talk ⋅dgaf)  13:53, 30 May 2018 (UTC)

I think parameter suppression is a useful ability to have, and has been requested before. Even if not widely used, it is preferable to removing the template completely. This should be pushed independently of the above proposal on hiding un-referenced imported data by default. — AfroThundr (t•c) 23:12, 29 May 2018 (UTC)
I'd suggest using a "suppressfields" parameter along the lines of Module:WikidataIB, as that's more explicit than a blank parameter. Mike Peel (talk) 23:36, 29 May 2018 (UTC)
The blank parameter method may be a bit more intuitive (local override) than a separate suppression parameter. Plus editors may expect this behavior to be consistent with other infoboxes that also use the blank parameter method. Nothing saying we couldn't also add a suppressfields parameter as well. — AfroThundr (t•c) 00:51, 30 May 2018 (UTC)
Please keep it simple: VIAF=xyz should set the VIAF link to whatever is specified, and VIAF=none should suppress the display. Johnuniq (talk) 02:55, 30 May 2018 (UTC)
I would encourage the possibility to have the possibility both to local override (per Johnuniq’s method as that is most simple, and have a possibility to suppress the display of the parameter, but have it invisibly transcluded (so that search engines ‘see’ it, and index it, but it does not clutter the page or suggest that there is anything encyclopedic about the information it displays or links to). Note that this is separate from any discussion about whether we should or should not use WikiData from this. —Dirk Beetstra T C 03:20, 30 May 2018 (UTC)
Fields suppression is a good first step, but eventually we need to either limit the main AC template to the few genarlly accepted and useful ACs for enwiki, and have supplementary AC templates for more specific ones (e.g. use the Italian national library only on subjects with a clear link to Italy, not on everyone who ever had a book translated in Italian); or have a template where only the ACs explicitly mentioned get displayed (AC|VIAF|BNF|LOC wuold display those three and no others). Fram (talk) 07:04, 1 June 2018 (UTC)
The problem with "VIAF=none" is that someone might take that to mean 'no VIAF number exists', and get confused when they see it elsewhere / try to add it manually to fix the problem. Mike Peel (talk) 12:15, 1 June 2018 (UTC)
Exactly. Same with ‘VIAF=‘, where editors are going to remove it as ‘empty, probably mistake as it does not do anything’. The only way is a manual opt-in. And that is crazy, having ‘VIAF=WD’ on each page where we want a VIAF, it takes all the automation away (but leaves any underlying problems). —Dirk Beetstra T C 04:20, 6 June 2018 (UTC)
The only way is a manual opt-in That's not true. You could just as easily have something like |suppress=VIAF, DNB, etc. to suppress a list of fields. You can name the suppression parameter whatever you wish, of course. A number of infoboxes use |suppressfields= (as Mike points out) because |parameter= is ambiguous, and because you're right about manual opt-in for this application. --RexxS (talk) 23:33, 6 June 2018 (UTC)
That is indeed an option. However, if for a page it is decided that VIAF and DNB are the only two we want to display, we now have 41 to suppreess. And if someone adds a parameter (see discussion at bottom), I might have to follow up to suppress the 42nd as well (unlikely that this one needs suppressing, but you get the idea). You could now say that you only need to suppress the 20 that currently have a value set on WD, but if someone then sets one of the 21 that would be transcluded then you would need a follow up edit to suppress that as well. It becomes rather unmanageable except for doing the opt-in or local parameters (and yes, I think that in ALL cases we should limit display to a core number, the rest should be hidden). —-Dirk Beetstra T C 23:56, 6 June 2018 (UTC)
Given the flood of options/proposals that appeared, suppression via null parameters still seems like the KISSiest approach, is the most intuitive, doesn't attempt to juggle named vs. unnamed parameters, and has the most support. Bulk removal of default params is still an option but requires a separate & longer discussion about each param affected.   ~ Tom.Reding (talk ⋅dgaf)  11:50, 6 June 2018 (UTC)
No, it is the KISSiest approach if you insist to use WikiData (though confusing if you suppress 15 out of 22, with more to come and possibly suppress). The true KISSiest approach is WYSIWYG, local data in local parameters. —Dirk Beetstra T C 14:46, 6 June 2018 (UTC)
That is assuming a change in the default template behavior to disable Wikidiata transclusion by default. That is something that should be discussed separately from the option of suppressing individual options. Even if we change the default transclusion behavior for many of the identifiers to prune down what gets included automatically, we'd still want the ability to suppress and override as necessary. — AfroThundr (u · t · c) 15:02, 6 June 2018 (UTC)
It is a variant, or possible in combination. I am not sure if we need to separate this, we need a solution to the excess (note, there are WD discussions for more authority-type parameters going on on WD, we have 22, we can do 43, how many are there on WD that we could have ...). —Dirk Beetstra T C 15:52, 6 June 2018 (UTC)
@Tom.Reding: This discussion seems to have died down - what are the next steps? Nikkimaria (talk) 21:33, 23 June 2018 (UTC)
Nikkimaria, parameter suppression via null parameters has been implemented as of 3 days ago and reflected in the /doc, along with the associated tracking category, Category:Wikipedia articles with suppressed authority control identifiers (currently empty) to check for potentially wanted (suppressed after June 20th) or unwanted (suppressed before June 20th) usages. So far, I've only seen and corrected 2 or 3 in that category with last-edits on those pages being from ~February.
There's a definite desire for parameter suppression, with null/blank being the simplest, most intuitive, with the most support. If we see huge swaths of similar parameters being suppressed, then that can/will/should raise a red flag that we need to reconsider that parameter's use on en.wiki. That, in turn, can provide support for a smaller subset of IDs. If that doesn't happen, and there's a roughly even, or statistically insignificant, distribution below some threshold of nullified parameters, then support will be made for those parameters' inclusion. Time will tell.   ~ Tom.Reding (talk ⋅dgaf)  22:51, 23 June 2018 (UTC)
@Tom.Reding: Just to be sure, the migrating bots, or any other bots, do not remove empty/NULL params, do they? —Dirk Beetstra T C 04:50, 24 June 2018 (UTC)
KasparBot seems to remove them: https://en.wikipedia.org/w/index.php?title=S._D._Chrostowska&diff=prev&oldid=844012238. —Dirk Beetstra T C 05:37, 24 June 2018 (UTC)
Regardless of that [bots removing empty parameters], this will cause problems, but we now have a way to see that. —Dirk Beetstra T C 05:58, 24 June 2018 (UTC)
@KasparBot and T.seppelt: suppression via empty parameters is now a feature on en.wiki so these types of edits are probably no longer necessary, or at least should be done more carefully now to check that the empty parameter was added prior to the implementation date of 20 June 2018 (I'll make a note of this in the tracking cat).   ~ Tom.Reding (talk ⋅dgaf)  14:14, 24 June 2018 (UTC)
@Tom.Reding: there are from before, all articles now have no empty parameters, except for the ones added now. Not sure if there are other bots that do this too. —Dirk Beetstra T C 15:48, 24 June 2018 (UTC)
Beetstra, that's a reasonable concern. See my scan at the top of this section, though, which produced only 2 empty parameter usages out of 175k scanned pages. Being extremely isolated, it's not likely that any bots are bothering with such cleanup (you've found the most likely contributor, I think, since KasparBot is even mentioned in the /doc). Because of these factors, I think the job queue will apply this suppression to all transclusions well before any bot goes and remove them. So we should see all rightful-suppressions in the tracking cat first. I'm going to be keeping tabs on the cat too over the next week to look at any additions (already 1) or subtractions.   ~ Tom.Reding (talk ⋅dgaf)  17:22, 24 June 2018 (UTC)
@Tom.Reding: In addition to the suppression, were there any plans to implement the "pull from Wikidata" mechanism mentioned below to display identifiers not included by default? I believe that would be more useful than editors defining them locally. — AfroThundr (u · t · c) 17:12, 6 July 2018 (UTC)
AfroThundr3007730, that's a separate issue that would require more discussion. I'm against pulling all IDs from WD by default, and in favor of limiting them to those that pass consensus here at en.wiki, which may or may not include pulling all of them. However, I think WP:SILENT consensus after several days to a week can suffice when it comes to ID-addition.   ~ Tom.Reding (talk ⋅dgaf)  21:43, 7 July 2018 (UTC)
Well I meant single ID overrides, like mentioned below, instead of showing all Wikidata IDs. You would then be able to force one to display by including the parameter, but not setting it to anything (ex. |VIAF= |HDS | would suppress VIAF, but pull HDS from WD). I figured it'd be useful to be able to override the default behavior in both directions. — AfroThundr (u · t · c) 23:56, 7 July 2018 (UTC)

Suppression follow-up 1

Should Category:AC with 14 elements‎-type cats reflect the total # of elements available on WD (i.e. status quo/no change) or should they reflect the # displayed on WP (i.e. if/when we start locally suppressing params)?   ~ Tom.Reding (talk ⋅dgaf)  23:19, 31 May 2018 (UTC)

The number on enwiki surely? I don't see why it would be important here to know how many authority control elements there are at WD, considering that they have quite a few we will never display on enwiki in the AC template anyway (Quora, Freebase ID, Findagrave, ...). Fram (talk) 07:00, 1 June 2018 (UTC)
I find it disturbing that we have up to 22 (maybe more) displayed in some articles wihout anyone wondering whether they are useful. There is no per-article selection as in the pre-WD time. The motto seems to be: “Now we have WD, USE IT!” —Dirk Beetstra T C 07:57, 1 June 2018 (UTC)
Well, I guess it is useful for our readers to have a direct link to the bibliographic record for Immanuel Kant in Japan, Czechia, Sweden, Spain, Italy... plus, of course, a Musicbrainz ID. Only 18 here, on Wikidata you get 69 (more or less) of these! Fram (talk) 08:43, 1 June 2018 (UTC)
I've updated my original post (in bold) to be more clear.   ~ Tom.Reding (talk ⋅dgaf)  11:08, 1 June 2018 (UTC)
  • I'd just scrap those categories. I'm not sure why it's helpful to know that 14, 15 or 16 IDs are shown/available. Mike Peel (talk) 11:10, 1 June 2018 (UTC)
  • As to the original request, it should show how many we transclude, so it could be prioritized which need cleanup/suppressing. —Dirk Beetstra T C 11:39, 1 June 2018 (UTC)
    • How does knowing the number shown help with prioritization? Mike Peel (talk) 12:14, 1 June 2018 (UTC)
      • 22 is excessive, those articles should be cleaned upfirst. It does not make sense to start with the ones showing 4 only (although I agree, seen the fully automated transclusionand lack of editor control likely there there will be some which are not needed either). —Dirk Beetstra T C 04:17, 6 June 2018 (UTC)


Proposal

The proposal below uses the asterisk (*) as wildcard symbol. It represents a value that is substitutedtranscluded from Wikidata.

Two authority control systems are used as example:

Expected behaviour:

  • {{Authority control}}
    • Displays the Wikidata VIAF number (if there is one at Wikidata)
    • Does not display the Wikidata HDS number
  • {{Authority control |VIAF= |HDS= }}
    • Displays neither a VIAF nor a HDS number
  • {{Authority control |VIAF=* |HDS=* }}
    • Displays both the Wikidata VIAF and HDS numbers (if they are present there)
  • {{Authority control |VIAF=123456 |HDS=98765 }}
    • Displays the local VIAF number (123456) and local HDS number (98765)
  • and combinations, e.g. {{Authority control |VIAF= |HDS=* }}
    • ... no VIAF number, and displays Wikidata HDS number (if there is one at Wikidata)

The above proposal does not take a position yet on whether some of these might better be completely removed from English Wikipedia's authority control box.

The above does also not take a position yet on which ones would almost always be useful and which ones would have a too limited applicability to always display them in the box. The proposal is just about the principle how things could work practically.

The above proposal does also not take a position on whether a "suppressfields" parameter should be implemented (too).

Nor does the proposal take a position on whether the "*" wildcard is a suitable (or even technically opportune) symbol to indicate "import Wikidata value if it exists". Any more suitable string would be acceptable to me, on the condition that it is short (one or two characters), and easy to remember, e.g. "wd" would work form me too. --Francis Schonken (talk) 11:51, 1 June 2018 (UTC)

Proposal Discussion

  • I like it, it includes the typical blank parameter suppression method, and allows for exposing identifiers that don't typically show, if needed.
Suggestion: Instead of an asterisk, just specify the parameter with no equal sign, so |HDS|.. to force a pull from Wikidata. This would still allow for suppression with the empty value, e.g. |VIAF=|....
Full example: {{authority control|VIAF=|HDS}} would suppress the VIAF identifier, and pull in HDS from Wikidata. Thoughts? — AfroThundr (u · t · c) 11:54, 1 June 2018 (UTC)
Like it, even easier for editors imho. --Francis Schonken (talk) 12:28, 1 June 2018 (UTC)
  • You're lumping 2 proposals together: the wildcard one, and removing |HDS= from the suite of displayed-by-default AC IDs.
I like the wildcard idea, which is useful for WD AC IDs which have not been/will never be displayed by default in AC.   ~ Tom.Reding (talk ⋅dgaf)  12:07, 1 June 2018 (UTC)
  • Bad idea. * normally represents 'all', so it's confusing to use that instead to mean 'none'. It's better to use the suppressfields option, as that's clear and unambiguous. Mike Peel (talk) 12:10, 1 June 2018 (UTC)
    • Wait, you're using an odd ordering for the examples. So * here means 'fetch it from Wikidata'? If there are multiple values, does it fetch them all, or just one? The more I try to understand this, the more confusing it gets. Mike Peel (talk) 12:12, 1 June 2018 (UTC)
      • Re. "odd ordering" – no, it is the ordering at Template:Authority control#Usage, both the "Full" and "Blank" usages, and also as ordered in the table included in that section.
      • Re. "If there are multiple values ..." – it means (and if you read the proposal up to its last paragraph you'd see I'm not attached to symbols), just "fetch the same for that parameter as the {{authority control}} now fetches". --Francis Schonken (talk) 12:28, 1 June 2018 (UTC)

The proposal, how I read it, is to:

  • A. Divide the IDs in some which get shown by default (like VIAF) and some which get hidden by default (like HDS)
  • B. Provide a mechanism to hide any ID you want (by using IDname=)
  • C. Provide a mechanism to show any ID you want (by using IDname)
  • D. Provide a mechanism to override any ID you want (by using IDname=XXX)

which certainly would be better than the current situation. Fram (talk) 12:19, 1 June 2018 (UTC)

Indeed. --Francis Schonken (talk) 12:28, 1 June 2018 (UTC)

Variant proposal

 – AfroThundr3007730's suggestion

Two authority control systems are used as example:

Expected behaviour:

  • {{Authority control}}
    • Displays the Wikidata VIAF number (if there is one at Wikidata)
    • Does not display the Wikidata HDS number
  • {{Authority control |VIAF= |HDS= }}
    • Displays neither a VIAF nor a HDS number
  • {{Authority control |VIAF |HDS }}
    • Displays both the Wikidata VIAF and HDS numbers (if they are present there)
  • {{Authority control |VIAF=123456 |HDS=98765 }}
    • Displays the local VIAF number (123456) and local HDS number (98765)
  • and combinations, e.g. {{Authority control |VIAF= |HDS }}
    • ... no VIAF number, and displays Wikidata HDS number (if there is one at Wikidata)

The above proposal does not take a position yet on whether some of these might better be completely removed from English Wikipedia's authority control box.

The above does also not take a position yet on which ones would almost always be useful and which ones would have a too limited applicability to always display them in the box. The proposal is just about the principle how things could work practically.

The above proposal does also not take a position on whether a "suppressfields" parameter should be implemented (too). --Francis Schonken (talk) 12:36, 1 June 2018 (UTC)

Variant Proposal Discussion

  • Prefer the variant over my original #Proposal. --Francis Schonken (talk) 12:36, 1 June 2018 (UTC)
  • Support as proposer. It's more intuitive and avoids the confusing use of a wildcard character.
If an explicit value is necessary for the "pull" mechanism, maybe a plus sign (example: |HDS=+|) or allow both methods? — AfroThundr (u · t · c) 12:50, 1 June 2018 (UTC)

Local parameter proposal

If there is a parameter ‘VIAF=1234’, then display ‘1234’. If there is not, don’t display anything. Advantages: it does what it says on the box, no confusion, local editor is responsible for what is there (no surprise values popping up in the future that need a follow up edit to suppress it), problematic edis can be traced back to the editor (and if needed locally sanctioned). —Dirk Beetstra T C 12:54, 1 June 2018 (UTC)

This could be accomodated by adding a wikidata=no global switch in the template. Or if that's not wanted, you could always fork a copy or make a wrapper to disable Wikidata transclusion. Probably better to just add a global suppression flag, although I can't think of a case where WD should be completely suppressed. — AfroThundr (u · t · c) 21:44, 1 June 2018 (UTC)
So you prefer to have a template that confusingly suppresses what we don’t want (for, say, 40-60 parameters), so it would only show the three you want (which, confusingly for newbies, magically appear). AC is an uncontrolled mess, (at the moment) up to 22 parameters shown, and the only solution you have is to suppress what you don’t want (where someone adds code for a next parameter, and you have to perform an edit on each page where you dont want it, otherwise it gets transcluded wherever WD has the data and someone has to also check whether it is appropriate, correct, on each page it transcludes in order to check for policy violations). All those problems are avoided, so yes, I would want that, simple clear WYSIWYG transclusion of ONLY the values that you want. —Dirk Beetstra T C 03:48, 2 June 2018 (UTC)
So a global suppress flag then? That would accomplish what you're looking for. If you use {{authority control |wikidata=no |VIAF=12345 }} the template would not import any identifiers from Wikidata even if they existed. Local parameters would be the only data source, and in the example, only the VIAF would be displayed. This is al assuming a global suppress parameter gets implemented, of course. — AfroThundr (u · t · c) 05:36, 2 June 2018 (UTC)
No. Read what I say. You have a random page with a non-globally-suppressed AC. Someone adds a handful of identifiers to the corresponding WD item - voilá - a farm of identifiers appears. Are they all wanted? You don’t know, so someone from en.wikipedia has to come and suppress them? Or do you expect that the responsible WD editor will come over and suppress the ones that are unneccesay (I do not)? This is one of the main problems with wikidata, we will be running constantly behind WD edits that change/add something here post-template edit to see whether it is correct, whether it is for that case sufficiently referenced with repect to OURpolicies, and whether we should have it at all in the first place. Combine that with the lack of control, vandalism/spam fighting and sufficient policy on WD, and I get to the same point as everywhere else: WD is not ready at all, and when (if) they become, our policies and guidelines are not ready. This is creating a fait accomply that will only result in problems. Are you guys kidding me, 22 transcluded identifiers without any control whether they should be there? This should, for all articles, be on (at best) a strict opt-in basis (with maybe max 3 automated?), which Hardly makes any sense (for nearly any identifier a ‘XXX=yes’-type option? Just confusing). —Dirk Beetstra T C 06:15, 2 June 2018 (UTC)
Or do you expect that any editor who adds AC here will go to WD to check all are proper? Most are added by bot anyway, because WD has identifiers to transclude. —Dirk Beetstra T C 06:17, 2 June 2018 (UTC)

ID division proposal

Compatible with #Proposal or #Variant proposal above, and taking a stance on which ones could be removed from the box altogether.

Background philosophy
Two aspects play a major role in deciding which identification numbers to include in the {{authority control}} box:
  • unique identification of an article topic (which for me represents the "core business" of the template)
  • providing useful links (above WP:ELNO threshold)

Proposal:

  1. Display by default:
    1. 'BNF', 'BNF', 268, p.bnfLink
    2. 'GND', 'GND', 227, p.gndLink
    3. 'ISNI', 'ISNI', 213, p.isniLink
    4. 'LCCN', 'LCCN', 244, p.lccnLink
    5. 'NARA', 'NARA', 1225, p.naraLink
    6. 'NARA-organization', 'NARA', 1223, p.naraorganizationLink
    7. 'NARA-person', 'NARA', 1222, p.narapersonLink
    8. 'ORCID', 'ORCID', 496, p.orcidLink
    9. 'USCongress', 'US Congress', 1157, p.uscongressLink
    10. 'VIAF', 'VIAF', 214, p.viafLink
  2. Display only when called explicitly:
    1. 'BIBSYS', 'BIBSYS', 1015, p.bibsysLink
    2. 'BNE', 'BNE', 950, p.bneLink
    3. 'Botanist', 'Botanist', 428, p.botanistLink
    4. 'DBLP', 'DBLP', 2456, p.dblpLink
    5. 'HDS', 'HDS', 902, p.hlsLink
    6. 'Joconde', 'Joconde' , 347, p.jocondeLink
    7. 'KULTURNAV', 'KulturNav', 1248, p.kulturnavLink
    8. 'NCL', 'NCL', 1048, p.nclLink
    9. 'NDL', 'NDL', 349, p.ndlLink
    10. 'NKC', 'NKC', 691, p.nkcLink
    11. 'NLA', 'NLA', 409, p.nlaLink
    12. 'RID', 'ResearcherID', 1053, p.ridLink
    13. 'RKDartists', 'RKD', 650, p.rkdartistsLink
    14. 'RLS', 'RLS', 947, p.rslLink
    15. 'SBN', 'ICCU', 396, p.sbnLink
    16. 'SELIBR', 'SELIBR', 906, p.selibrLink
    17. 'SIKART', 'SIKART', 781, p.sikartLink
    18. 'SNAC-ID', 'SNAC', 3430, p.snacLink
    19. 'SUDOC', 'SUDOC', 269, p.sudocLink
    20. 'ULAN', 'ULAN', 245, p.ulanLink
  3. Remove from box (meaning: use a dedicated template such as {{CPDL}}, {{MusicBrainz work}}, {{RISM}}, etc, or another format of external link, when you want to include an external link to the authority file):
    1. 'ACM-DL', 'ACM DL', 864, p.acmLink
    2. 'autores.uy', 'autores.uy', 2558, p.autoresuyLink
    3. 'BALaT', 'BALaT', 3293, p.balatLink
    4. 'Bildindex', 'Bildindex', 2092, p.bildLink
    5. 'BPN', 'BPN', 651, p.bpnLink
    6. 'CINII', 'CiNii', 271, p.ciniiLink
    7. 'LIR', 'LIR', 886, p.lirLink
    8. 'Léonore', 'Léonore', 640, p.leonoreLink
    9. 'MBA', 'MusicBrainz', 434, p.mbLink
    10. 'MGP', 'MGP', 549, p.mgpLink
    11. 'PIC', 'PIC', 2750, p.picLink
    12. 'RKDID', 'RKDimages ID', 350, p.rkdidLink
    13. 'TLS', 'TLS', 1362, p.tlsLink

As long as an identifier from list #3 is still in the box, it would appear under list #2 conditions. Meaning, it needs not be decided instantly (under #Proposal or #Variant proposal) whether or not an identifier system is thrown out of the box altogether. --Francis Schonken (talk) 14:17, 1 June 2018 (UTC)

Discussion on ID division proposal

  • I'd be reluctant to see these identifiers stripped completely. If they're suppressed by default, they're not hurting anything by being in the template code. Plus there are scenarios where their inclusion would be a positive addition to an article.
I also believe we would be better served by consolidating as many of those other templates as feasible. We could have one well-maintained authority control / unique ID template to cover most™ needs. This is excluding any of those that provide some unique functionality not covered by {{authority control}}. — AfroThundr (u · t · c) 21:52, 1 June 2018 (UTC)

Just use Wikidata and a set of identifiers

Since there are so many complicated options being proposed above, I thought it might be worth proposing that we just stick with the simplest option. Let's have a standard set of identifiers that we want to display, and use Wikidata to provide the ID values. If the IDs are wrong, then fix them on Wikidata (and hence everywhere else that uses the Wikidata values). We can then focus on which identifiers we want to display here, rather than getting distracted about whether to show one value or the other. Thanks. Mike Peel (talk) 01:13, 5 June 2018 (UTC)

No, because what is to be included is to be a per-article choice. There is no one size fits all. —Dirk Beetstra T C 03:15, 5 June 2018 (UTC)
They're identifiers. They're standard. One size fits all sounds fine. Mike Peel (talk) 13:20, 5 June 2018 (UTC)
what I mean is that depending on the class of articles, origin of subject, etc. a different set of identifiers is appropriate. There is no need to show all. —Dirk Beetstra T C 14:03, 5 June 2018 (UTC)
In those cases, the identifiers already vary based on the scope of the identifiers. There's no need to do more than that. Mike Peel (talk) 14:31, 5 June 2018 (UTC)
Mike, why would we, on enwiki, show identifiers for e.g. the Spanish, Italian, Japanese or Swedish national library for subjects which have no connection to either of these languages / countries? That these libraries have an identifier for these subjects is normal; that Wikidata, which is multilingual, has these is also normal. But how do we serve the reader with posting many IDs indiscriminately instead of focusing on those with actual value for our readers, i.e. a few high quality general ones (VIAF and so on), and a few subject-specific ones (e.g. the Italian national library for people from or active in Italy, but not for e.g. some Dutch author with one translation in Italian once). What's the value of having this on Pieter van Musschenbroek in enwiki? Why should we show this on Thomas Hobbes?
"One size fits all" is not reader-friendly when you have too much information (IDs), burying the useful ones among the here unuseful, distracting ones. There clearly is a need to do more than what the template allows now, if we really want this template to give the best possible result for enwiki readers. Fram (talk) 14:46, 5 June 2018 (UTC)
We have 'one size fits all' readership - we don't change the content depending on whether a reader is from Spain, Italy, or France, or the US. So that means having a 'one size fits all' list of identifiers, and the readers can then look for the ones that are most relevant to them. Mike Peel (talk) 14:56, 5 June 2018 (UTC)
This is one of the main reasons I proposed the value suppression above. With this proposal, editors will be able to control what appears in the template locally (|VIAF=1234 |), as well as what does (|HDS |) or doesn't (|HDS= |) get pulled from Wikidata. Most importantly, the default template behavior will not change for everyone else who's okay with the status quo. — AfroThundr (u · t · c) 15:35, 5 June 2018 (UTC)
(ec)No, we actually don't have a one-size-fits-all readership, that's why Wikipedia is multilingual. The ones most relevant for our readers are the one that have either the most information, or information in the language they are reading here. That's the same as we do with sources, external links, ...: if there are similar sources or external links in English and in other languages, we use the English sources. We e.g. normally never add Italian or Spanish language external links to pages about people not related to these languages / countries. But I would expect that eswiki or itwiki did exactly that. So why pretend that for AC things would or should be differently and that we suddenly must cater to another audience? Fram (talk) 15:40, 5 June 2018 (UTC)
If you believe that, then surely that's a case for not showing given identifiers full stop, not one for wasting editor time by having to manually pick them. Mike Peel (talk) 16:24, 5 June 2018 (UTC)
I don't see how your reply follows from my statement at all. I explicitly state that some identifiers are clearly useful and welcome on nearly every article, and that others are only useful on some articles, even if they exist for a lot of other articles as well (and some are not welcome at all, but that's a different discussion). If you mean that this is an argument for removal of these IDs from the AC template, and adding them through some other template where wanted, then yes, that's a solution I would support. They don't even have to be "manually picked", you could add e.g. a template "Swedish identifier" to all biographies in the project Sweden (just thinking out loud here, this is not some ultimate proposal to vote on). I would prefer this to lots of "switches" in the main AC template which would have to be set (by bot or manually) on each article, but having such switches is better than the current "show them all" approach. Fram (talk) 16:42, 5 June 2018 (UTC)
As always with WikiDataians, there is only one way, the way where transclusion can be automated and one-size-fits-all. If that gets challenged you get either other-crap arguments or you are accused of not liking WikiData. If you cannot supply the data that is specifically chosen to be included for said article then we cannot use that method for transclusion. 22 identifiers is absurd, and that number is likely not the max we have. And the only solution that can be discussed is suppression of what we don’t want, while it is so easy to get what we want (and that is much easier for the occassional editor to understand: no magic involved. Combine that with the lack of control, that WikiData is, also for this, an unreliable source to get this info (even if in this case it is primary sourced by definition) makes me get to the conclusion that we are, at best, not ready for wikidata. I look forward to an RfC with solutions and discussion. —Dirk Beetstra T C 17:45, 5 June 2018 (UTC)
Having groups of identifiers and selecting those for different topics would work OK - much better than picking individual identifiers. You could even have an automatic switch based on the country of citizenship (P27) or similar. I won't comment on Dirk's rant apart from to agree that an RfC of some sort is probably needed here if you want to change things. Mike Peel (talk) 18:10, 5 June 2018 (UTC)
Mike, have you read your previous comment not one for wasting editor time by having to manually pick them .. that is exactly the only way - WD SHALL be used. You will not consider other options. Seen the previous RfC, and that this goes deep in community, proper RfCs are likely the only way. —Dirk Beetstra T C 04:14, 6 June 2018 (UTC)

ArhivX LOD

Should ArhivX LOD be added? Peaceray (talk) 06:37, 31 August 2018 (UTC)

Crockford's Clerical Directory

Crockford's Clerical Directory is the authoritative directory of priests in the Anglican Communion, covering a large number of notable subjects in category:Anglo-Catholic clergy and subcategories. Guy (Help!) 17:07, 15 August 2018 (UTC)

JzG, I couldn't find a Wikidata property for Crockford's, except this other one that mentions it. I recommend you make a property proposal at d:Wikidata:Property proposal/Authority control, then it can be added and handled seamlessly by the module.   ~ Tom.Reding (talk ⋅dgaf)  19:18, 31 August 2018 (UTC)

Interested Parties Information

My question if a composer's IPI code is better used in Musician Infobox or be a subject of Authority Control (Property 1828)ZJ (talk) 11:15, 21 September 2018 (UTC)

MusicBrainz

MusicBrainz appears to be a WP:USERG site. Why are we including its content? I think it should be removed. Toddst1 (talk) 22:03, 3 October 2018 (UTC)

Previous discussions: Template talk:Authority control/Archive 7 § MusicBrainz at ELN → Wikipedia:External links/Noticeboard/Archive 21 § MusicBrainz
Also related: Template talk:Authority control/Archive 7 § Bot request to place template on all biographies → Wikipedia:External links/Noticeboard/Archive 21 § Authority control
— AfroThundr (u · t · c) 01:56, 4 October 2018 (UTC)
Retrieved from "https://mdwiki.org/wiki/Template_talk:Authority_control/Archive_7"