Citations
From WhyNotWiki
Citations edit (Category edit) .
Aliases: Quotes (writing), Citing sources
See also: WhyNotWiki:Citing sources
This is for the topic of quotes as in anything that is quoted by another person, in the context of Writing, where we might be interested in proper attribution, integrity of quotes, adding annotations to the quote.
This page is for discussion about quotes/citations, but is not for the quotes themselves.
http://www.webster.com/cgi-bin/dictionary?va=citation :
- 2 a : an act of quoting; especially : the citing of a previously settled case at law b : EXCERPT, QUOTATION
Contents |
[edit] Templates
[edit] Contract for users of quotes
When you say that something is a quote, what are you promising? What contract are you implicitly entering into?
Here's my take...
You are giving your best-faith assurance that:
- the words contained within your quote are word-for-word the same as the source that you are quoting (if you aren't so certain about the word-for-word exactness of it -- as when you are transcribing a quote from memory that you heard -- you may be better of using an "almost-quote")
- that any formatting that is necessary to to convey the full meaning of the author's words be retained. (If you can be certain that all formatting is kept in-tact -- for example, if there wasn't any to begin with -- then you can call it a Quote with formatting) Examples of essential formatting: formatting used for emphasis, ... . See also: Non-essential formatting.
- that you aren't taking the quote grossly out of context. If you do take the quote out context and fail to provide the context using the original author's own words, then you are obligated to provide sufficient context with your own words.
[edit] Permissible liberties:
- minor punctuation changes: changing "--" to "—", etc.
- dropping off the beginning of a sentence and capitalizing the first word of your new sentence as if it were the first word of the original sentence...provided the part of the sentence you dropped wasn't essential to the meaning. ([N]o brackets are necessary in this case.) An example of something that it's perfectly okay to drop: transition words, like "But", "However", and "So".
- typo fixes: I expect this is probably a controversial topic (and I welcome other viewpoints on this), but here's my opinion: as long as the meaning isn't altered, I go ahead and fix typos, going with the word that the author intended rather than the word (technically a non-word most of the time) that he actually accidentally used. Why make the quotee unnecessarily look like an idiot? The prevailing alternative I've seen is to include the typo, but to assure readers that it's the quotee that is an idiot and not you by including the annotation
[sic]. - You don't need to retain all hyperlinks, only those that are of interest to you, although you should retain "important" hyperlinks. You still need to retain the text of the hyperlink (!), but it can be rendered as plain text in your citation rather than as a hyperlink. (Also, the target of the hyperlink need not be noted when doing a plain-text citation.)
- The order of unordered lists (t.i., bulleted lists) may be changed (if there is a good reason to). (One good reason for doing so would be so that you could put a single ellipsis at the end of the list rather than having to put one in between each range of un-omitted list items.)
[edit] What do you think you should be able to get away with changing when you quote someone?
Here are my initial thoughts:
- Formatting stuff. You can change "WHY" to "*why*" or "_why_" or "why" or "why" -- the point is that the emphasis that the author put on "WHY" is retained. As long as you retain that meaning, you are free to change the formatting to match the style of your composition.
- Omitting or ***-ing out offensive material. If you are offended by some of the words someone uses (profanity, sacrilege, etc.), I think it's okay to substitute something neutral in its place (enclosing it in [] to show the substitution) or just omit it entirely (probably using ... to indicate the omission).
- Expanding acronyms (maybe use
[]) - Fix typos, maybe even without noting it with a
[](I changed "You'll e-mail will bounce" to "your e-mail will bounce" without making a note of it--it was obvious that's what was meant!) I don't want to help the proliferation of wrongly spelled words (or quotations containing [corrections marked like this] or [sic])! - Copy editing, fixing grammatical errors. I might be pushing my luck here... But if someone makes a run-on sentence with a comma, I might change it to a semicolon, etc.
[edit] Upgrades / Downgrades
See Template:Quotation edit for details, since that's where this feature is implemented.
[edit] Editorial changes ([stuff in brackets])
[edit] [Ambiguity (category)][Question (category)]: Do the brackets indicate a parenthetical comment (an addition) or a replacement?
It's ambiguous! This is a fairly large problem, in my opinion.
Example: I recently found myself making this editorial change:
You often want to add behavior to your classes beyond database storage and retrieval.
to:
You often want to add behavior to your [models] beyond database storage and retrieval.
But the reader would have had no way to know that "models" was a replacement for classes if it weren't for the fact that the syntax of the statement wouldn't have allowed it to be anything but a replacement (there had to have been a noun after "your" before -- so my "[models]" annotation must not simply be a parenthetical comment about the word "your"). (This is not always the case. [To do: find example].
Should I have done this instead?:
You often want to add behavior to your classes [(models)] beyond database storage and retrieval.
It's debatable. In my opinion, the author should have used the word "models", thus justifying my use of a replacement. However, a parenthetical comment would have probably also worked.
Another option would be to use a "strikeout" font decoration to show that it's a substitution rather than an addition. However, this is fairly ugly, conspicuous, and distracting, and it's easy to see why we don't see this [convention] in common use.
You often want to add behavior to your
classes[models] beyond database storage and retrieval.
Or yet another idea:
You often want to add behavior to your ... [models] beyond database storage and retrieval.
Proposed solution: Use two different kinds of markup: one for substitutions and one for additions (we already have one for plain old omissions (...)).
Substitutions could possibly use a symbol that's a mix between [] and strikeout:
You often want to add behavior to your
[models]beyond database storage and retrieval.
While additions could use a symbol that's a mix between [] and + ...
[edit] Ellipses (...) ("editorial omissions")
... or [...]??
[...] is certainly more distracting. Might have it display "[...]" if copied/exported to raw text but use font size/CSS styles to make it prettier when viewed on the Web.
[edit] Context of quotes
All quotes are taken out of some larger context. Usually books, speeches, articles, conversations, etc.
"Omissions": Because they are almost always taken from some larger work, I don't think we need to put "omission marks" (...) at the beginning or end of the quote — that's already implied! It's only the inner omissions that need to be documented.
One question is: how much of that context needs to be described in the citation? With books, usually the book details and a page number is sufficient.
[edit] Omissions
I think it might be helpful to distinguish between sentences and paragraphs.
For instance, if I quote a paragraph and the beginning or end (sentence) of a paragraph is omitted, I might want to annotate that somehow. Even if this sentence omission is at the end of the quote (i.e., there are many paragraphs following my quote in the larger work), I still might like to show that. For example:
I believe that the purpose of life is, at least in part, to be happy. Based on this belief, Ruby is designed to make programming not only easy but also fun. It allows you to concentrate on the creative side of programming, with less stress. [...]
From that (assuming I adopt this convention), you can know that you just read the entire beginning of the paragraph, although some parts near the end were omitted (and obviously many paragraphs before and after this section).
[...] for within paragraphs (sentence / word / phrase omissions); just ... for paragraph omissions?
[edit] Omitted paragraphs
Normally I would indicate the omission of one or more (any number of them) with a simple "...":
I believe that the purpose of life is, at least in part, to be happy. Based on this belief, Ruby is designed to make programming not only easy but also fun. It allows you to concentrate on the creative side of programming, with less stress. If you don't believe me, read this book and try Ruby. I'm sure you'll find out for yoursellf.
...
It is my hope that both Ruby and this book will serve to make your programming easy and enjoyable. Have fun!
[edit] [Open questions (category)]
What if, however, the paragraph that is omitted is preceded by a paragraph whose final sentence(s) are already omitted? Should we do it like this to indicate that there is an omission of both sentences and paragraphs?:
I believe that the purpose of life is, at least in part, to be happy. Based on this belief, Ruby is designed to make programming not only easy but also fun. It allows you to concentrate on the creative side of programming, with less stress. [...]
...
It is my hope that both Ruby and this book will serve to make your programming easy and enjoyable. Have fun!
or just let the sentence omission mark be enough and not mention that paragraphs were omitted?
I believe that the purpose of life is, at least in part, to be happy. Based on this belief, Ruby is designed to make programming not only easy but also fun. It allows you to concentrate on the creative side of programming, with less stress. [...]
It is my hope that both Ruby and this book will serve to make your programming easy and enjoyable. Have fun!
This is a stumper to me. I don't like wasting vertical space just to indicate omitted paragraphs. On the other hand, I don't like to leave it ambiguous and possibly mislead the reader.
Another alternative for discontinuous quotes: put each span of contiguous quoted paragraphs in their own quote blocks:
I believe that the purpose of life is, at least in part, to be happy. Based on this belief, Ruby is designed to make programming not only easy but also fun. It allows you to concentrate on the creative side of programming, with less stress. [...]
It is my hope that both Ruby and this book will serve to make your programming easy and enjoyable. Have fun!
[edit] Question/ambiguity: Source's editorial omission or mine
When the reader sees a "..." in a quote where I'm quoting a source, how does he know if that was my editorial omission (omitting something that was in my source) an inherited editorial omission (an editorial omission that existed like that already in my original source)?
Obviously we need some kind of markup to distinguish between the two. (Just like we need to be able to distinguish between the two for all editorial markup (stuff in [brackets]).)
[edit] Allowed annotations/markups
- Highlighting -- currently I just use underlining but I should switch to a more semantic markup tag sometime soon...
- Underlining -- underlining is the one form of markup that is assumed by default (when you don't explicitly mention whose markup it is) to be your own and not that of the original author's. Therefore, it is the preferred way to highlight something.
- Highlighted text could also be displayed using different background colors (equivalent to a highlighter pen in a book).
- (Choose one or the other, since in the end we'll have only one tag for this: either show all "highlighted" text using underlines or background color.)
- Your "editor's" notes should go in brackets, [like this] to distinguish them from words of the author. (Question: How then would we know if some brackets actually were from the original source?)
If you italicize or bold something, you must provide a note that says "italics are mine" or equivalent.
If the italics or bold was from the original source, then no note need be provided (that is, the default authorship of those markups is assumed to be the original author).
[edit] Problems
[edit] Delimiters for quotes within quotes
If you delimit your quote with, say, a blockquote then you shouldn't also put actual quote marks around the quote or else they might be interpreted as being a part of the quote.
So I guess it's only a problem if the quoter is silly and delimits his quote in two or more ways (most common case would be by using blockquote indentation in addition to quote marks).
