What is a citation?
As a part of Zotero and ODF discussions of citations recently, we’ve stumbled on a tricky issue that impacts on a lot of different pieces to the puzzle of robust and reliable citation formatting. The question for today is, what is a citation?
Let’s examine an example rendered in author-date style:
(Doe, 1999:25; see also Smith, 2000)
So how to model this? What to do with the cited page number, and the “see also” bit? How to encode it so that it’s easy to sort and reformat?
One option is to just say that a citation may have one or more references, each of which can contain parameters for cited pages and prefixes or suffixes. Graphically (think in terms of RDF), this might look like:
This is rather complex; probably more than it needs to be.
Another option is to treat the cited page not as a parameter of some reference abstraction, but to more directly encode what the user intends: namely to cite the item fragment itself.
That’s simpler. Hmm …
Come to think of it, I’m not sure it’s correct; the “see also” prefix isn’t really for the source, but rather for the reference to the source. So maybe we can’t throw out the reference abstraction just yet.
Moreover, we’re left with another, even more fundamental, problem. The “see also” prefix in fact references to a different kind of reference. As such, it gets sorted differently within the citation. So if you have a style that says to sort references within the citation according to author-date, it needs to group such references at the end of the citation, sort within that group, and attach a prefix to the entire group.
So a formatting system that fully supports real-world citation styles really ought to understand that this is a different kind of reference; something like:
Admittedly, option 3 would require some cleverness to make this all fully intuitive and natural for the user. It would also likely result in limiting the flexibility users are accustomed to with other applications like Endnote. However, in that case, users are basically forced to handle all this themselves, so it seems a small loss in flexibility is balanced by a fairly big payoff in automation.
I don’t see what was wrong with option 1. Seems wonderfully clean to me. Citations are composed of one kind of thing. It’s 2 and 3 that seem more complex, since in them citations have two kinds of things, and one of the two might need to get converted to the other if the user adds a page number.
Why did you say that 2 and 3 “directly encode what the user intends”? Are you presuming that users think of references-with-page numbers as semantically different kinds of things than references-without-page-numbers. I don’t. Style guides don’t, do they?
I might put in a reference, with or without locater. Later make a change. Add page number, change to chapter number, drop locater completely, back to adding a chapter number, add a suffix. I don’t think I’m constantly converting items to segments and vice versa.
(Doe, 1999:25; see also Smith, 2000) looks to me like it’s made of two apples, not an apple and an orange, and certainly not like an apple and an orange that could be converted into an apple if I add some property.
Where you thinking that a prefix or suffix also changes an item into a something else? You left these two off option 3.
I like option 1.
Hi John,
Let me demonstrate with a more complex example. User drags-and-drops on, or otherwise simultaneously inserts, three references in their document: two from one author, and a third from another author.
Their citation style (like, say, APA), says that the references need to be sorted. Where there is more than one from the same author, author name should be dropped from all but the first.
So how do you get (Doe, 1999, 2000; Smith 2001)?
If working right, it happens automatically. I really shouldn’t have to reorder the references, and then select the second one and click some gizmo that says “don’t display author name”. This is how Endnote does it, but we can do better; right?
Do we agree so far?
OK, now, what happens if I decide the first Doe references and the Smith are both see also references? I am not actually citing them as the source for the preceding information (maybe data, or a quote, or an idea), but merely just pointing users to it.
Output, then, should be:
(Doe, 2000; see also Doe 1999, Smith 2001).
Now, how does the software achieve this?
A few months ago, did you ever think about the distinction between footnoted citations and citations in footnotes? Maybe you did; just curious.
I’m not sure style guides don’t point us in this direction. Chicago, for example, says “In notes or parenthetical citations, where reference is usually to a particular passage in a book or a journal, only the page numbers pertaining to that passage are given” (section 16.13). Seems to me the object here is the passage; not the full resource.
But to be more concrete, imagine Zotero implements the functionality some have requested to be able to define a note as an excerpt, and include a page number in it. If the user copy-and-pastes that note text into their document, shouldn’t that logic travel with it such that the citation is automatically rendered?
[note: looking at this again, I suppose the example right here is a bit of red herring, as you could probably achieve it with any of the approaches; will leave it anyway.]
This is indeed a good point I’d not thought about. Still, I’d like to hold aside implementation details just now and worry about the basic logic.
But you do see that you’re now responsible for sorting those references yourself; right?
Or am I missing something?
I need to think about that one some more.
(How do I get those cool indents? Does that magically happen if I quote your text?)
You asked: A few months ago, did you ever think about the distinction between footnoted citations and citations in footnotes? Maybe you did; just curious.
Yes actually, when I first used Endnote. Didn’t think of it much again until I saw something about CSL or CiteProc and thought, “Someone here understands citations. Cool!” Then tried using Zotero. “Oh-oh. Not right.”
Anyway, back to “What is a citation?”
(Doe, 1999, 2000; Smith 2001) (Doe, 2000; see also Doe 1999, Smith 2001)
I don’t see why any option is better than model 1 for handling this. In model 1, just query the references collection and do a sort-and-group on prefix, name, and date, in that order. Give the null string preference in the sort.
User enters three references
prefix: item/author: Doe item/year: 2000
prefix: item/author: Doe item/year: 1999
prefix: item/author: Smith item/year: 2001
Sort-and-group yields (Doe, 1999, 2000; Smith 2001)
User prefixes two of them with “see also”.
prefix: item/author: Doe item/year: 2000
prefix: see also item/author: Doe item/year: 1999
prefix: see also item/author: Smith item/year: 2001
Sort-and-group yields (Doe, 2000; see also Doe 1999, Smith 2001)
No?
Yes, just use blockquote tags to get the indent.
OK, fair enough. So what happens if we get:
prefix: se also item/author: Doe item/year: 1999
prefix: see also item/author: Smith item/year: 2001
…? Seems fragile to be relying on string comparison entered by users to be doing grouping and sorting, doesn’t it? And in that case, isn’t a user in fact implicitly doing what is explicit in option 3?
I’m partly asking this question for practical here-and-now “how should Zotero do it?” reasons, but I’m also asking from a future-oriented best practices standpoint: because I’m likely to have to define exactly how this should work in ODF 1.2. There, the logic will be encoded in RDF, which of course is a simple graph-based data model. Hence the diagrams
And we’ll be living with the implications for a long time to come.
Come to think of it, while we’re at it, how about integrating the discussion of uncited refs, etc.?
Then the user would get (se also Doe 1999; see also Smith 2001), see the mistake, and fix it.
Doesn’t seem so to me.
If in fact there is a canonical set of common prefixes, they could be provided, maybe as a dropdown list or list of radio buttons, as “Mr.”, “Mrs.”, “Ms.”, “___”, might appear on a form today.
But I don’t see the need even for this. There’s no telling what writers will want in a prefix (or a suffix). - see - see also - see for comparison - cf. - compare - cf. translation in - contra - pace - further discussed in - in addition to - see especially - quoted in - as suggested by And that’s just English.
Let writers enter whatever they want. If they misspell “suggested” and get (as sugested by Doe 1999; as suggested by Smith 2001), too bad for them. They’ll figure it out. They’d rather that than to be told that because they might misspell one, we have limited them to prefixes we have selected.
So just to be clear, then, you would define the algorithm/model like so? - a citation has one or more references - each reference has one required ID (a URI) - each reference has optional prefix and suffix parameters - each reference has optional locator parameters for page numbers, etc. (only one, or possibly multiple?) - within a citation references shall be grouped by prefix
I guess that would work. Are we safe saying that common prefixes ALWAYS indicate in effect a group?
Also, how to sort the groups?
Finally, what about my question about uncited and such? Did we conclude that tags achieve this? And if yes, then does that suggest as well a reference: - may have one more “group” tokens (notcited, notlisted, etc.)?
And if yes, then wouldn’t it be appropriate to define “see” and “seealso” as possible values? If not, how do we explain why?
Yes, that’s my proposal, with one clarification or amendment: I believe references are an ordered, not unordered list, and that the order is determined by the user. If a style forces sorting by date, the user’s order will get overridden, but if the style is neutral on the subject, the user’s order prevails. So the data model stores the user’s order, not the order as presented.
I think: Only if they are contiguous in the user’s order.
I earlier said references should be sorted and grouped. In fact, I think it should be first sorted by user order, then grouped by prefix, then sorted and grouped as the CSL defines.
Assume the user enters (in this order)
see also Doe 1999 contra Smith 2000 see also Jones 2002 see also Jones 2001 see also Anderson 2004
If the CSL does not demand grouping or sorting, then references get presented in the user’s order, with the prefixes grouped. This case would also be common with note-based styles.
(Miller 1990; see also Doe 1999; contra Smith 2000; see also Jones 2002, Jones 2001, Anderson 2004)
If the CSL demands references be grouped by name, listed alphabetically, and ordered newest to oldest:
(Miller 1990; see also Doe 1999; contra Smith 2000; see also Anderson 2004, Jones 2002, 2001)
I think that works. Yes?
By this algorithm if the user entered the following
see also Doe 1999 contra Smith 2000 see also Jones 2002 Jones 2001 Anderson 2004
he’d get, assuming the same CSL,
(Miller 1990; see also Doe 1999; contra Smith 2000; see also Jones 2002; Anderson 2004; Jones 2001).
Maybe that’s not what he wanted, but it is what he asked for, formatted as the style guide says. I don’t think we can presume that a reference without a prefix inherits the prefix of the previous. If that should be assumed or defaulted, it could be handled in the user interface.
I think uncited or notlisted is a different issue and is a property of a source, not of a citation. We should take that up on a separate thread.
“So how do you get (Doe, 1999, 2000; Smith 2001)?”
I agree with John that your first model seems nice and clean.
I think in your model that is a citation that contains three references, but at output the software notices that the first one and the second one share the same name, and the name doesn’t need to be output twice.
What is output on screen doesn’t need to exactly match your model–it just needs to be modeled by it! I think you want to keep your model clean, and to some extent actually mapping the concepts involved. Which, for that citation, are to me, a citation with three references. The second just happens to be the same author as the first, which means that APA style (or whatever) says not to write the same name twice.
The model should be seperate from the output according to a given style–it just needs to be able to model it!
Jonathan: I think you misread the intent of my example there. It was simply to say the processor has to know what references to group and sort, and how. In other words, they need to be encoded/modelled in a way for them to be reliably presented in different ways depending on the style.
While I think the first option (the one you and John prefer) might well be the pragmatic one that reflects the way this software has often worked, I don’t really think it precisely models what’s going on. I’m sorry, but a “see also” reference is semantically different than a generic citation. And the strings “see also” and “cf.” are just conventions to express that.
But I’m not attached enough to that position to think it important to argue about. So long as John and others can program the software so the stuff works, that’s the primary goal.