Wikipedia talk:Citing sources

See WP:PROPOSAL for Wikipedia's procedural policy on the creation of new guidelines and policies. See how to contribute to Wikipedia guidance for recommendations regarding the creation and updating of policy and guideline pages.

Khai khrop

Hello - I would appreciate opinions on a situation I've encountered in the past couple of days, involving the article Khai khrop. It came up during New Page reviewing, and I tagged it for needing improvements to citation style as it had no inline citations (still doesn't at this time). After a bit of back-and-forth with an editor who is building the article, s/he removed the citation style tag with the edit comment "rm pointless maintenance tag: article uses a perfectly normal text-only inline variant of the harv style: if anyone dislikes it feel free to change it any way you want". The article is something I know nothing about, so I'm not about to get more involved in it.

References have been supplied in this article, but as general footnotes, without inline citations. I would appreciate more eyes on this little situation - if the editor's opinion is valid according to Wikipedia policy, then great - file closed. However, if his/her opinion on not needing inline citations is offside, can somebody with more gravitas please step in to 'advise' the editor to not remove a reasonable 'citation style' tag? Thanks in advance! PKT(alk) 22:20, 8 December 2017 (UTC)

PKT is mistaken. Parenthetical referencing is an acceptable method of providing inline citations, and this style of referencing is being used in the "Khai khrop" article. Jc3s5h (talk) 23:27, 8 December 2017 (UTC)

(edit conflict) Citations ought to use the relevant templates to ensure that both formatting and links are in a standard style. Regardless of this though, the article needs inline references such as {{sfn}} to link the assertions to the cited sources. It would also help, but is not required, if the sources were in English - it's pretty hard to check them if they use a differnt script and language. I've reformatted one of the citations (because it was the only English one) and use {{sfn}} to point to it. I trust that will be an example for all to follow. Martin of Sheffield (talk) 23:44, 8 December 2017 (UTC)

But see WP:CITECONSENSUS: "... The use of citation templates is neither encouraged nor discouraged ...". Wtmitchell (talk) (earlier Boracay Bill) 01:02, 9 December 2017 (UTC)

• I guess I'm the ultimate culprit here: I'm the one who removed the maintenance template that PKT had diligently placed on the article: I simply don't think the prime real estate at the top of an article should be wasted on big warning signs about exceedingly minor issues. Yes, the citation system is a bit wonky, but it's still clear and within reasonable distance of the standards. Martin of Sheffield, thank you for showing the world that snf exists! You're absolutely welcome to convert the remaining four citations to use it, but what you have done so far is to simply introduce inconsistency. Now, I just started looking for the guidelines that talk about consistency in citation style, but hey, we're already on their talk page! – Uanfala (talk) 01:33, 9 December 2017 (UTC)

Feel free to revert, I'm trying to help here. The OP asked for opinions on the situation due to a minor disagreement. There are several advantages in using the citations as well as consistency; for instance is "Mthai food" retrieved from http://food.mthai.com or is it from http://food.mthai.com/food-inbox/90416.html? The citation templates can also be used to add internal links. As regards {{sfn}}, again feel free to use any other method including moving the citations inline, but you do need to provide the link from assertion to citation. Don't let your sarcasm blind you to the need to do this somehow. "(ครูฑูรย์, 2012)" is one way to do it, but do remember that this is the English language wiki and very few readers will be familiar with Thai script. See WP:NOENG. You also need to aim for at least one reference per paragraph. Regards, Martin of Sheffield (talk) 12:07, 9 December 2017 (UTC)

Consistency in citation style

Does consistency in citation style imply that if one citation uses author last name and initials, one should not use last name and full first names for other citations in the same article?

Not to me. Suppose you decide on last name and full names as the style: you can't always use this style because the full names aren't always given in the source. If you decide the other way, and settle on initials as the style, then there's a problem with Chinese names (and some other Asian names). Consider a real example. One contribution to the Flora of China has its authors given as "Zhanhe Ji & Alan W. Meerow". We can turn "Alan W. Meerow" into "Meerow, A.W." (with or without a space between the initials) but different sources use "Ji, Z.", "Ji, Z-H.", "Ji, Z.-H." or "Ji, Z.H." when converting two "word" Chinese first names into initials. The IPNI – the official source for the names of botanical authorities – generally splits such names (see here for example), so "Ji, Z.H." is the more "official" for botanists.

The best solution in my view is to reproduce the usage in each source, and ignore minor inconsistencies. Peter coxhead (talk) 09:48, 14 December 2017 (UTC)

Both of those suggestions appear to be both practical and logical, and pretty much what I do anyway. However, there are occasionally GA and FA reviewers who claim that consistency in citation style does imply that all citations in a given article must either give full names or initials only, and that this is written somewhere. I am still waiting for one of them to link me to the policy, rule, criteria or guidance where this is specified, and asked here in case there actually is something I have missed. It seems that if there is then you two have also missed it... Cheers

It is certainly a consistent citation style to always use the author names as they were written in their publications, regardless of the fact that some publications might use initials and others might not. That's how MathSciNet generally lists its citations, for instance. —David Eppstein (talk) 11:43, 14 December 2017 (UTC)

Agreed. And any other approach, as I've argued above, is simply not possible in all cases. Peter coxhead (talk) 11:46, 14 December 2017 (UTC)

It doesn't have to be possible in all cases to be possible within a single article. —David Eppstein (talk) 11:57, 14 December 2017 (UTC)

RFC: Accurate dates in citation metadata

The RfC discussion below, was based on the assumption that COinS cannot properly accomodate non-Gregorian dates. There seemed to be some uncertainty about whether this was actually the case. This close is based on the same assumption, and should be disregarded if the contrary is found to be true.

There is clear and strong consensus that non-Gregorian publication dates should not be fed into COinS, because they will generate inaccurate and misleading data. Users have highlighted the potential dangers of uncontrollably spreading false information. As was noted by WhatamIdoing, different solutions to this problem may require large amounts of work. As such I would not wish to declare a consensus for any one particular solution to the problem. There is merely a consensus for the end-goal to be obtained: that of not feeding Julian dates into a system that assumes and declares them to be Gregorian. The simpler but broad brush solution proposed, is that of blocking all COinS data generation for any date of publication before 1924. This of course would exclude many Gregorian publication dates as well, while a more complex to implement solution might not. The issue of the method of implementation, should be left to the person willing to implement the end-goal. @Trappist the monk: indicated that they may look into implementing the consensus of this, and so I'm pinging them in this close.

Finally, An important distinction was drawn by multiple commenters, between the use of dates for general bibliographic purposes and COinS style metadata collection (see in particular the final comment by J. Johnson). This RfC should not be viewed as having any consequence on the way Julian dates should be cited on Wikipedia, except insofar as it pertains to metadata generation. --Brustopher (talk) 14:38, 17 December 2017 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

For citations that emit metadata for publication dates, is it necessary that the value of the date agree with the calendar that the metadata purports to use? For example, if a publication is 1 July 1750 Julian calendar, and the metadata emits it as 1 July 1750, Gregorian calendar, is this acceptable? Jc3s5h (talk) 14:54, 26 September 2017 (UTC)

Discussion of Accurate dates in citation metadata

This issue was raised at Help talk:Citation Style 1#Truthful publication dates but I believe it should be discussed by a wider audience. I believe metadata should be either accurate or absent. The simplest fix for the problem is to avoid emitting publication dates with a precision of a day or month if the year of publication is earlier than 1924, since Greece was the last country to change its civil calendar from Julian to Gregorian. Jc3s5h (talk) 14:54, 26 September 2017 (UTC)

• Of course the software should not be publishing wrong dates because of a technical error. This is the kind of mistakes that could be copied by others and perpetuated forever, becoming incredibly difficult to fix. Why do we need an RfC for this? If an article contains a date in the Julian calendar, a metadata system that can't handle Julian dates shouldn't be reading it. Diego (talk) 15:34, 26 September 2017 (UTC)
• Whatever date format the underlying database uses, the software should be capable of converting a date in any calendar and style to and from the database format. The citation templates don't have a way to specify what calendar is used in the date parameter; for accuracy, an extra paramater is needed, and quite a lot of conversion code, and validation. — Stanning (talk) 15:52, 26 September 2017 (UTC)
• A date on a publication is just a black box. If the source itself says "July 10, 1812" then our citation templates should also include the date as "July 10, 1812". It is incorrect to view the date string as being in particular calendar. It is just a string, like the author's name, which we should repeat without changing, for the sake of accuracy. It would be inaccurate for us to change the date to something other than what is written on the item itself. It is up to the person who reads the citation to interpret the date in whatever way they prefer, and this is facilitated only by us presenting the date exactly as the publication itself does. We do not need to hamstring ourselves based on COINS; we can simply say that we emit COINS-like citation information, which a consumer needs to interpret correctly. We certainly should not avoid stating the date at all solely because some documentation for COINS refers to a particular calendar. — Carl (CBM · talk) 21:51, 26 September 2017 (UTC)

• I submit that since most of the COinS data is read automatically rather than by human eyes, creating data in the COinS format is an irrefutable statement that the data follows the COinS standards, and no footnote on some obscure page in "Wikipedia:" space can turn a false date into a true date.

I do agree that we shouldn't change the date; if the source says July 10, 1812, then we should not change it to July 22, 1812. (Although it isn't just a string; changing it to 10 July 1812 would be acceptable). Let the COinS community fix their broken standard to support an unspecified calendar. An unspecified calendar is best for our purposes, since we may not know which calendar a particular date is stated in. Jc3s5h (talk) 22:16, 26 September 2017 (UTC)

If we just emit the literal date entered by the user, I don't see that as a false date - I see it as our best effort to specify the date. For most of the uses of Coins, which I think are to automatically populate our citation info into other bibliography managers that will go on to treat the date as a black box, I don't see any likely problems from just passing the date unchanged. In the relatively rare cases where a person cares what calendar a citation to an old work is in, they would have to work it out manually, of course. After all, we are not talking about using these dates to synchronize clocks or anything like that. — Carl (CBM · talk) 23:11, 26 September 2017 (UTC)

A problem I see is the people who write standards and software do not necessarily work with a wide range of dates and documents. My personal suspicion is they like to work with documents that were "born on the web", airline tickets, hotel reservations, and the like. My concern is that someone like that will blindly look at the specifications, have no personal knowledge of how they are used outside the 21st century, and blindly use the data as if it were correct. If you don't give them wrong data, they might just notice and look into the issue. Jc3s5h (talk) 23:30, 26 September 2017 (UTC)

I agree. But would they be more likely to notice a void of data, or data that blows up on them? Or (as I suggest below) embargoing all use of COinS? ~ J. Johnson (JJ) (talk) 22:21, 27 September 2017 (UTC)

• No. "Agreement" with a supposedly "purported" calendar is not necessary, and this idea of "accurate dates" is incorrect.

I don't like this notion that it is "up to the person who reads the citation to interpret the date in whatever way they prefer". Where publications (sources) have dates more specific than just year – typically newspapers, magazines, government bulletins, military orders, etc. – that is a definite datum not open for interpretation or alteration, and which we should ALWAYS supply as specifically and completely as possible, as otherwise we greatly impair verifiability. (Note that omitting the day or month does not make the remaining part less accurate, only less precise.) That a date may be incorrect if the wrong calendar is assumed is not an issue of date "accuracy", but in the assumption of a calendar, and we should not be coercing dates into any specific calendar

But perhaps what Carl means is that without any indication of which calendar a date is based on a reader may have to use some judgment. That should not be any problem, as most commonly there are only two alternatives. It is certainly a lesser problem than not having a complete date.

Whether the "metadata system" can "handle" Julian dates is not an issue, as all of Julian/Gregorian/cs1/COINS "handle" date strings as years, months, and days. I don't know that any metadata "purports" to use any calendar, and I don't believe it really matters, just as a book that says it was published in September but didn't come off the presses until November would still have September as its publication date. The only exception I can think of would be a source that claimed dual Old Style and New Style dates, but that is such a special case we need not worry about it. ~ J. Johnson (JJ) (talk) 23:33, 26 September 2017 (UTC)

Anybody who follows a complex standard well enough that many external projects, like Zotero can read it, is sending a strong message to the world that they are following the standard. COinS is a way to encode OpenURL, which in turn is specified by ANSI/NISO Z39.88-2004 (R2010) The OpenURL Framework for Context-Sensitive Services. That standard says a date follows W3C Date and Time Formats Submitted to W3C 15 September 1997. That in turn says it is a profile (that is, subset) of ISO 8601, which in turn requires the Gregorian calendar. So COinS cannot handle Julian dates; they are forbidden. Jc3s5h (talk) 00:49, 27 September 2017 (UTC)

I don't see that ISO 8601 forbids all use of Julian dates, only that it sets the Gregorian calendar as the common reference for comparison. The problem seems to be that CoinS wants everything referenced to Gregorian. More on this below. ~ J. Johnson (JJ) (talk) 22:10, 27 September 2017 (UTC)

I don't have a copy of ISO 8601 that I'm free to copy excerpts from. But I can point you to a page linking to a discussion draft of the next ISO 8601. It claims that Part 1 is essentially the same as 8601-2004 (with some corrections). Part 1 of the discussion draft "is essentially the same as 8601-2004 (with some corrections)". Part 1 states on page 7

This International Standard is applicable whenever representation of dates in the Gregorian calendar, times in the 24-hour timekeeping system, time intervals and recurring time intervals or of the formats of these representations are included in information interchange.

This implies the standard is inapplicable whenever other representations are to be included in information interchange, such as dates in the Julian calendar, or times stated with a 12 hour clock (e.g. 3 PM). Jc3s5h (talk) 10:40, 29 September 2017 (UTC)

Not exactly, unless there is some language that "inapplicable" applies to all cases not explicitly included. Lacking that, applicability for non-Gregorian calendars might be "undefined". Though I suspect it is the intent of 8601 to have all representations of time absolutely referenced to a common system of type "Gregorian". However, the problem is not with 8601, but with COinS: was it intended to coerce all dates into the Gregorian calendar? Or is that an unforseen and unintended consequence of adopting (albeit implicitly) 8601? The intent may have been to rely on 8601's tremendously useful standardized representation of a date for the purpose of information interchange, which works just as fine for Julian dates. But without requiring conversion to an absolute reference, which is not needed for citation work.

Of possible interest here: have any other "emitters" of COinS data dealt with Julian dates? Or for that matter, with Iranian dates? (I seem to recall seeing some modern works dated per the Iranian calendar.) Even better: how do libraries handle Julian (etc.) dates? (See below.) ~ J. Johnson (JJ) (talk) 22:03, 29 September 2017 (UTC)

• I think the cleanest solution is to add parameters for other calendars, not used by default, and always do a one-way conversion to Gregorian if one of them is used. Emit an error if two are used or one is used and |date= is manually filled and does not match the auto-calculation. Use that calculation to emit COinS Gregorian dates, which is the only format that spec can handle. Displayed to our users should be something like DD Month YYYY (Julian: DD Month YYYY) or Month DD, YYYY (Hijri: Month DD, YYYY), always putting modern, Western, Gregorian date first to agree with all the other date presentation on this site. No alternative dates should be shown if one taken from the source wasn't supplied to the template, since our goal is not to show converted dates in all the various calendars. The goals are and only are to a) have a consistent Gregorian-calendar date for our users (even if not a consistent date format, MDY vs. DMY) and for COinS users, and b) preserve the in-source date in another calendar if and only if that source used one (and didn't also provide a Julian date). In other words, avoid adding date-conversion trivia.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:45, 27 September 2017 (UTC)

• After reading the discussion so far, my idea of the cleanest solution is to add a language calendar parameter. For the time being, if the calendar parameter is absent or set to anything other than "Gregorian", the precision of the date is better than year, and the year is earlier than 1924, the metadata for the publication date is suppressed. This avoids emitting a converted date, which will confuse readers when the citation says 9 December 1745 but when they get an image of the Stamford Mercury from an archive it says 28 November 1745.

Later, after the COinS community fixes their standard to properly accommodate non-Gregorian calendars, the citation templates can be edited to follow whatever the improved COinS standard says to do, and all the citations will be instantly improved. Jc3s5h (talk) 16:54, 27 September 2017 (UTC). Corrected 06:11, 29 September 2017 (UT) Jc3s5h.

Like you say, converted dates are confusing. But they can be useful. Which leads to a somewhat subtle difference in the use of dates for comparison, and for identification.

In some cases – e.g., examining press coverage of the opening days of World War I in various countries using different calendars – it helps to have all dates referenced to a common calendar (typically the Gregorian). (Though I think a chart would be better.) But in bibliographical work a publication date is more of an identifier. If a source asserts a certain publication date then the asserted date is the controlling identifier, even if it is known that the "real" date was months later. It is analogous to pseudonyms: while we know that the "author" of The Adventures of Tom Sawyer is really Samuel Clemens, what the book actually says is "Mark Twain".

That COinS wants (?) to coerce all dates into Gregorian calendar therefore undermines the use of publication date as a bibliographical datum. Which suggests another option for us: embargo all COinS metadata until that standard is fixed.  :-)

For us, setting a calendar parameter has some merit. But there will always be cases where the calendar is not known (and arguably not even relevant), and making the default an assumed Gregorian leads to error. It might be better that the default (at least for dates prior to 1924) be "undefined". And let COinS choke on that. ~ J. Johnson (JJ) (talk) 22:16, 27 September 2017 (UTC)

Agreed. We agonize way too much over a crappy metadata spec that is a minor side matter when it comes to WP's purpose. This dates-as-identifiers rationale is also a good reason to replace unnecessarily precise publications dates (copy-pasted from Amazon) with just years for books. We do not need a |date=13 September 2015 for a book.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  22:38, 18 October 2017 (UTC)

You know what? Unless Jc3s5h is proposing to do this work himself, then I think that whatever User:Trappist the monk wants to do with the CS1/2 modules is fine with me. Nobody really wants inaccurate dates, but – we're WP:VOLUNTEERs, and this feels a bit like "I volunteer someone else to do all the hard bits". WhatamIdoing (talk) 01:54, 29 September 2017 (UTC)

Hold on, Trappist the monk has no power there, does not own the cs1|2 modules. Trappist the monk may or may not choose to do the work to implement whatever decision arises from this discussion but that is all.

—Trappist the monk (talk) 11:15, 29 September 2017 (UTC)

• Remember that we are talking about citations here. The only reason for including metadata (such as dates of publication) in a citation is to assist those who wish to read the source to find it (for example when searching in a library card catalog, or looking for a scanned copy in an on line database).

I am concerned that "correcting" a date would interfere with this. The question we should be asking isn't "Is this date accrurate?" but "What date is likely to be listed in a library's card catalog?". I suspect that most libraries would simply give the date printed in the source itself... and if I am correct about this, then we also need to be faithful to what is printed in the source itself. When it comes to citations being "faithful" to the source trumps being "historically accurate".

Now, in a different context ... for example when discussing the book in the text of an article about the book (or in the infobox of such an article)... then it might be appropriate to "correct" the date (or to give both Julian and Gregorian dates). But NOT in a citation. Blueboar (talk) 11:48, 29 September 2017 (UTC)

I think the WP:V policy would expect us to first, tell no lies. If what we want to express can't be expressed in a certain context, we shouldn't express it.

As for different contexts, with all the automated software roaming around cyberspace stitching together information, we can't expect that information given in the context of a citation will remain in that context. Consider automation that is assigned the task of finding out when a certain fact was first published. The automated process determines it was first published on January 1 in a Russian newspaper, but that's a Julian calendar date and the first publication was actually January 10, Gregorian calendar, in an English newspaper.

Of course, the automation could make the mistake anyway by screen scraping or parsing the |date= parameter in our wikitext, but at least we shouldn't lie by claiming it was a Gregorian date. Jc3s5h (talk) 14:24, 29 September 2017 (UTC)

WP:V does not really apply to the metadata of citations (if it did, we would have to cite our citations... and then cite those citations... ad infinitum). To put this another way - citations are the means by which we carry out WP:V. They are the means to verification of content.... not the content itself. (does that makes sense?). In terms of citation, it does not matter what the actual publication date of a source is... what matters is the listed publication date. Blueboar (talk) 15:59, 29 September 2017 (UTC)

The material in a citation can ordinarily be verified by consulting the work cited. If one were to annotate a citation with material that wasn't obvious, or contained in the cited work, it would indeed need a citation. And of course if the annotation (or in this case, metadata) is false, one won't be able to find a reliable source to support it. Verification is really a multi-step process: noticing the information in the citation, finding the source, reading the source, and comparing the information in the source to the article. A citation facilitates verification but is not, by itself, verification. Jc3s5h (talk) 19:22, 29 September 2017 (UTC)

As Blueboar says: yes, how do libraries catalog Julian dates? (Or other calendars.) Should we be faithful ("tell no lies") about what the source actually says is its publication date? Or the "real" time the asserted date corresponds to? Are we "lying" if we do not assert a calendar where COinS has not explicitly required that?

As to not expressing any date: isn't that kind of like cutting off one's face because one's nose is crooked? As a user of this data, it is going to be a lot easier to find my Russian newspaper article knowing it was published in January, 1914, (even if the day is "wrong") than just "1914". ~ J. Johnson (JJ) (talk) 22:07, 29 September 2017 (UTC)

J. Johnson (JJ) asked 'Are we "lying" if we do not assert a calendar where COinS has not explicitly required that?' If you use COinS, just by using it you're asserting all dates are Gregorian. Jc3s5h (talk) 22:13, 29 September 2017 (UTC)

Not at all! Assertions are positive, definite statements; some would say "emphatic" or even "forceful". Some thing I don't say can hardly be "asserted", no? Or is there some kind of hidden End-user license agreement here that legally inverts this distinction? ~ J. Johnson (JJ) (talk) 22:56, 29 September 2017 (UTC)

A small point about the "Russian newspaper" example. We are now used to news being reported immediately and therefore taking the reporting date as the event date. This just wasn't true in the past. An event might happen on Monday, the editor hears on Wednesday and sends a reporter and artist who travels by train on Thursday, returning Friday. The following Monday he writes up the article and the artist finishes the engraving by Tuesday missing the press deadline, so it is reported the following Thursday, 2.5 weeks late. If the event is further away or infrastructure breaks down, or it is before trains, then it might be 2.5 months. Now, is an argument about 1 Jan versus 10 Jan that relevant? Yesterday I was checking up on some death notices in the local weekly paper from c.1896 and they were often a week or two post mortem. Martin of Sheffield (talk) 09:31, 30 September 2017 (UTC)

Very true... and someone looking to read the newspaper account of the event will need to know the date of publication (i.e. the date printed on the newspaper where the account appears), not the date of the actual event itself. Blueboar (talk) 11:47, 30 September 2017 (UTC)

Just to illustrate the difference between dating in a citation, and dating in text... prior to about 1750 (I forget the exact year), England still started the new year in March... which means that a newspaper with a publication date of "February 15, 1735" and giving an account of an event that happened the day before, was actually discussing an event in (what we would call) 1736.

Now, which date should we use? It can get complicated... certainly when discussing the event in the main body of an article's text we should use (the updated) 1736, as that is the date of the event by modern standards. Writing the date in modern form helps the reader put the event in context with other events (otherwise the reader may get confused by the fact that an event occurring in February 1735 actually happened two months after an event that happened on December 1735... not several months before as you might assime)

However, If you go to a library and try to read this newspaper account, you will not find it if we used the modern form (1736) in our citation. The library database does not take the shift in dating into account. It uses the date printed on the newspaper (1735). So... For the purposes of citation we also need to use 1735... so that someone searching for the newspaper in a library can find it. Updating the date in a citation would be a disservice to our readers.

So... yes... an event that we say occurred in 1736 should indeed be cited to a newspaper with a date of 1735. Time travel! Blueboar (talk) 12:50, 30 September 2017 (UTC)

---

If we are all clear that the date of an event is not to be confused with the date of publication of a source: could we get back on-topic?

I should like to learn: how do libraries handle Julian dates? How do other generators of COinS data handle Julian or other non-Gregorian dates? ~ J. Johnson (JJ) (talk) 23:23, 3 October 2017 (UTC)

• The normal way of indicating a Julian year is either to say O.S. (for old style ) or use a dual date, e.g. 1698/9. See Old Style and New Style dates . As mentioned above, it is not just the shift of 10 or 11 days from Julian to Gregorian, but the usually simultaneous change in the Month when the year is said to begin (for example, for most purposes in England March until 1753 when it changed to January.) To the best of my knowledge, the articles I link to explain all this in accurate detail.

At least when I was a librarian, for most purposes libraries just try to get the year approximately right. Since conventional book publishing takes a considerable amount of time, there is always a period of several months at the turn of a year when the date on the book might be 1990 and the book actually published in 1991, or vice versa. Normally the cataloging record will just say whatever in on the book unless the discrepancy is more than one year. For journals, sometimes publication can be several years behind-- the papers for the volume intended for 1990 might not actually get published until several years later. (For purposes of academic priority, the key date is usually the date accepted for publication; for copyright and patents, when it actually appears.) For exact bibliographic purposes, or rare book cataloging, one tries to determine the exact date of publication and reports it will all necessary qualifier and explanations. There a large bibliographic literature on how to determine it, and on the various things that discrepancies can indicate.

Nice! Old Style and New Style dates is why I love Wikipedia: stuff I'd really like to know, but I can't do everything myself. And your comments are quite apropos here. Thank you. ~ J. Johnson (JJ) (talk) 21:35, 18 October 2017 (UTC)

For WP purposes, it doesn't much matter. When inserting a reference, I use whatever date in on the OCLC catalog record.

DGG ( talk ) 16:20, 17 October 2017 (UTC)

The "1698/9" style is going to be confusing for readers, as it's more commonly used (here, anyway) to indicate a span crossing a year boundary in the same calendar without exceeding an actual yaer, e.g. the 2009/2010 fiscal year, the 1998/1999 snooker season, etc. We could use "OS", I suppose, if it was linked to the Julian calendar article, e.g. OS. Or are we only concerned here with the COinS output?  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  21:48, 17 October 2017 (UTC)

The RFC is about metadata, so we are only interested in COinS. Since COinS only supports ISO 8601, the calendar is always Gregorian and the year always begins January 1. For the publication date presented in the citation read by a human reader, rather than a machine, WP:CITE allows any citation style, so one would try to discern which citation style is being followed (unless it's an ad hoc style just for that article) and read the associated manual or documentation, such as Chicago Manual of Style or Help:Citation Style 1. Frequently those resources will be silent on the issue, so the procedure adopted should be explained in a footnote. Jc3s5h (talk) 22:42, 17 October 2017 (UTC)

From DGG's comments I am more confident in my theory that, for bibliographic purposes, the importance of a "publication date" is not in capturing the exact moment in "time" (however it is pinned down) a source is "published", as for giving librarians, scholars, etc., an unambiguous identifier for (primarily) distinguishing different versions or editions of a work, and (secondarily) placing a given publication in the relative context of publishing history. As such, publication dates of "1776" and "1789" suffice to distinguish the first and fifth edtions of Smith's Wealth of Nations, and it matters not a wit whether those dates are New Style or Old Styler. Or even if the fifth edition was delayed and did not come until 1790. For bibliographic purposes "date" is simply a system of ordered identifiers. We don't need the precise number of seconds a date comes after (or possiby before) some event in 1970; that is entirely irrelevant.

On the otherhand, ISO 8601 is concerned with having an unambiguous data representation of actual time intervals. Which it pins to the Gregorian calendar. Jc3s5h has framed this discussion as a matter of accurate dates, and whether the value of a publication date should agree with "the calendar that the metadata purports to use" (i.e., the Gregorian calendar). But is this to be "accurate" in respect of a clock? Or of the "date" specified on the title page, by which a book is identified and catalogued?W

At 10:40 29 Sep. Jc3s5h quoted 8601 that it "is applicable whenever dates in the Gregorian calendar" are used, which he summarized as implying that 8601 is "inapplicable" (his emphasis) for other representations or calendars. If COinS requires (as he implies) Gregorian dates, then feeding it Julian dates is wrong. But so would be alteration of the data, or providing incomplete or misleading data.

I think there is a simpler solution: don't generate COinS data when an Old Style or non-Gregorian date is involved. That avoids any conflict between a COinS date and what is on the title page. ~ J. Johnson (JJ) (talk) 21:41, 18 October 2017 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikilinking authors in references

I noticed some wikignomes remove authorlinks from footnotes when a particular author is mentioned somewhere in the text. In my opinion, a wikilink to an author is useful in the "References" section, since the section is usually remote from article text where the name may have possibly be mentioned, and usually when I see a book, I am curious what else the author wrote, regardless article content. What is your opinion? Staszek Lem (talk) 00:19, 21 December 2017 (UTC)

Agreed. A related question is whether we should link only the first entry in the bibliography: there is a case for linking them all. When I end up looking at a bibliography item it's most often because I've been taken there by a link from the short citation: with this entry at the top of the screen I can't see without having to scroll up if there are any previous entries by the same author. – Uanfala (talk) 00:27, 21 December 2017 (UTC)

An example would be nice to see if there are any extenuating issues, but in principle I agree as well. PKT(alk) 01:14, 21 December 2017 (UTC)

My own tendency is to link all occurrences of the authors, except that I avoid linking an author of a publication within an article about that author. It makes it easier to copy and paste references that way, and also easier to tell which authors are missing articles (and might be a candidate for a new article). —David Eppstein (talk) 01:20, 21 December 2017 (UTC)

I agree that authors ought to be linked in footnotes, even if they are linked in the article text already. I think that in bibliographies, which should be in alphabetical order, per WP:REPEATLINK they should be linked on 1st occurrence only (possibly using |author-mask=). If the authorlinks occur in inline references, they should usually be linked every time. Linking when author=subject is obviously a bad idea. -- Michael Bednarek (talk) 04:55, 21 December 2017 (UTC)

Linking when author=subject is obviously a bad idea. Not necessarily so. In the cs1|2 templates, an |author-link= to the author page on the author page renders in plain text; it does not link to the current page nor does it bold the author name. There is some benefit to this because that template can be copied elsewhere and the link to the author's article works without need for tweaking the template. Additionally, |author-link= in combination with |author-mask= does not link the underscores that mask the author's name. And one last thing, setting |display-author=0 hides a linked author name; this can be useful when listing the author's writings (where the author is the only author).

—Trappist the monk (talk) 10:21, 21 December 2017 (UTC)

(squeeze) a) I didn't know that about CS1|2 templates; b) there are plenty of citations that don't use them, and that's what I, and I suspect David Eppstein, was referring to. -- Michael Bednarek (talk) 10:50, 21 December 2017 (UTC)

I sometimes link authors in references...if they have a Wikipedia article, of course. Flyer22 Reborn (talk) 05:06, 21 December 2017 (UTC)

And I commonly link the publishers. Flyer22 Reborn (talk) 05:07, 21 December 2017 (UTC)

To "link all occurrences of the authors" because "[i]t makes it easier to ... tell which authors are missing articles (and might be a candidate for a new article)" is a terrible "sea of red" idea and against our linking guidelines. We should never red-link anything not likely to be notable, and approximately 99.99% of writers are not notable, the vast majority of them being random news journalists, and most of those who are not being random academics. Please use WP:Common sense and link blue-links, and red-link cases where you are pretty sure we should have an article on the person.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:25, 23 December 2017 (UTC)

I meant only linking the authors with article; I tend to leave authors without articles unlinked, even when I'm convinced they're notable. —David Eppstein (talk) 02:39, 23 December 2017 (UTC)

General References

are articles allowed to consist only of general references? Are inline references essential?Egaoblai (talk) 19:07, 27 December 2017 (UTC)

As outlined at WP:GENREF, general references are allowed eg. when all of the content has a single source; generally better-developed articles use inline references. Nikkimaria (talk) 19:12, 27 December 2017 (UTC)

I am quite dubious of any article where "all of the content has a single source". (And especially if all of the content is supported from just, say, a single page.) The role I see for "general" references is where some source has something that applies "generally" to the whole article. (Though I have yet to see a clear instance of that.) But all the specific content in an article should be specifically cited. Which implies having inline "references". ~ J. Johnson (JJ) (talk) 22:44, 28 December 2017 (UTC)

Agree with the above answers. Or to put it another way: the answer to both of the questions asked is: Yes.

Articles are indeed “allowed” to be based purely on general references... however, inline references are indeed “essential” for any half way decent article to grow beyond a basic stub. Blueboar (talk) 00:52, 29 December 2017 (UTC)

A stub of a single sentence – and a short sentence at that, of a single fact or assertion – would be the limiting case of where a single "reference" specific to that content is effectively a "general" reference. But: where different points in the content are attributed to different sources, or even different locations within the same source, there needs to be in-line citations. We should not tolerate letting editors say (essentially) "I took material from these sources, and if you study them you should be able to determine from which one, and where." Wherefore I find any article (aside from a trivial stub) "based purely on general references" – that is, without any in-line citations – to be deficient. ~ J. Johnson (JJ) (talk) 23:26, 29 December 2017 (UTC)

Meh... it is possible to write more than a single sentence based on one single “general” reference... for example, on many topics you could write a multi paragraph “start” level article, cited entirely to the Encyclopedia Britanica entry on the same topic. Sure, we encourage editors to do better than that... and as the article grows we SHOULD do better... but something like that is acceptable to do in the early stages of a writing a new article. Blueboar (talk) 23:50, 29 December 2017 (UTC)

It is not forbidden, but it is creating a problem for later editors who will not know what all is attributed to that/those general references. The practice should be strongly discouraged as it is trivially easy to add inline refs to a general ref that is already defined. I think this is a remnant of very old (for Wikipedia) policy dating from the days before inline references were required. It is only marginally better than no references at all, and often practically equivalent. There are a lot of articles with general references listed in addition to inline, but they are for practical purposes useless for verification. It may be time to get rid of the option and only allow inline. · · · Peter (Southwood) ^(talk): 16:34, 31 December 2017 (UTC)

Sure, sometimes it takes more than one sentence to explain some item from a source, but that is somewhat of a special case. My point is that in the limiting case of where a stub contains only a single fact or assertion – perhaps I should qualify that with "no matter how many sentences it takes to explain that single fact or assertion" — then a single citation ("reference") suffices for verifiability, and it seems to hardly matter if it is in-line or "general".

(Except that it does matter. Addition of content outside of the scope of a "general" reference makes it no longer general. And if it is not made specific – i.e., in-line – it takes on a ghostly character.)

The problem with "general references" is where there are multiple elements that need to be cited, to either different sources, or different locations within a source, but an editor can't be troubled to add those details. (Lack of specificity is a slightly different but related problem.) As Peter says: we can't tell "what all is attributed to that/those general references." I can see sources being useful generally for understanding a topic, and perhaps even heavily relied on by an editor in evaluating and balancing the content, and therefore ought be referenced. But for purposes of verification specific content needs specific citation. Which is to say: in-line citation.

I agree with Peter that the typical usage of "general references" should be strongly discouraged. And, for the purpose of verifiability, should no longer be condoned. ~ J. Johnson (JJ) (talk) 21:21, 31 December 2017 (UTC)