Locators

CSL Development
1

I believe we discussed this issue before, but we need to do something
about locators. When citing a line in Zotero APA, we get:

Smith, 2001, ¶. 5

Notice the period after the paragraph symbol. That won’t do. So, we
have two options, as far as I can tell:

  1. Add each type of locator as a separate field. The “page” variable
    could then have a different meaning between the citation and the
    reference list.
  2. Add a locator attribute to the conditional (e.g., ).

Bruce and others, any opinions? We definitely need this by 1.0, which
gives us a few days to decide.

Simon

2

Simon Kornblith wrote:

I believe we discussed this issue before, but we need to do something
about locators. When citing a line in Zotero APA, we get:

Smith, 2001, ¶. 5

Notice the period after the paragraph symbol. That won’t do. So, we
have two options, as far as I can tell:

  1. Add each type of locator as a separate field. The “page” variable
    could then have a different meaning between the citation and the
    reference list.
  2. Add a locator attribute to the conditional (e.g., ).

Bruce and others, any opinions? We definitely need this by 1.0, which
gives us a few days to decide.

OK, we’ve got a few problems here. Let’s look at the locales file:

25     <!-- SHORT LOCATOR FORMS -->
26     <term name="page" form="short">
27       <single>p</single>
28       <multiple>pp</multiple>
29     </term>
30     <term name="paragraph" form="short">
31       <single>¶</single>
32       <multiple>¶¶</multiple>
33     </term>
34     <term name="volume" form="short">vol</term>
35     <term name="issue" form="short">no</term>

First problem, as I’ve mentioned before, is how to deal with “no” vs.
“n” (which is more common).

The second is the issue you note. Your solution makes sense, unless
we’re making a mistake treating that as a “short” form, and it ought
instead be called “symbol” or something?

Well, actually, even that change would support the locator conditional …

I’d say if you’re confident in it, just make the change.

Bruce

3

Yes, we definitely need another form of locator, for “no” vs “n” and
for “para” vs the symbol. Any ideas for a name for this form?

What types of locators do we need to support besides page, paragraph,
and line (the locators currently in Zotero)?

Also, what about plays, which can have more than one locator (act-
scene-line)? I suppose this presents a bit of a problem regardless,
since act and scene could be in Roman numerals. Perhaps we could just
make act-scene-line a locator type? Or do we need a more complicated
solution?

Simon

4

What types of locators do we need to support besides page, paragraph,
and line (the locators currently in Zotero)?

Glancing at a few style guidelines, I see the following mentioned and their
treatments specified. (I here express no opinion about which if any of these
require any special support.)

Classics: Many, many works that are now printed in multiple editions carry a
standard locator, usually based on some long out-of-print edition.

The Wealth of Nations is cited as vol.1, bk. IV, chap. II. Similarly for
many, many 17th, 18th, 19th century works. Shakespeare: Romeo and Juliet,
2.1.1-9.

Classics of antiquity each have their own now standardized locators.
Aristotle’s looks like 68b13, Plato’s 220d. Cicero’s uses the section symbol
(§).

Citations to books printed before pages were numbered usually use a
combination of numbers and letters, sometimes prefaced with fol. for folio.

(The above show up a lot in my own work.)

Dictionaries and encyclopedias use s.v. followed by the entry.

Religious texts have things like the Bible’s chapter and verse. Genesis
1:3-5, 2:4.

Legal? Music?

In locators, Chicago recommends these abbreviations:
figure: fig.
note: n.
notes: nn.
number: no.
opus: op.
page: p.
pages: pp.
part: pt.

MLA has their own abbreviations, and adds
verse: v.
verses: vv.

Legal uses
section: § and
sections: §§

I was pretty excited to see Zotero go beyond just pages, but there are still
more locators than page, paragraph, and line.

– John

5

Thanks for doing the research, John!

It seems like, for classics with their own standardized locators, we
shouldn’t do anything special. There’s no way we can possibly handle
all of them.

We should probably add all of the abbreviations you’ve listed to
locales.xml, and I’ll add locator types to Zotero. Given that many
styles specify their own sets of abbreviations, it seems like we’ll
want to add back the ability to redefine terms in CSLs, which never
made it into the new schema. It might even make sense to add “mla,”
“apa,” and “chicago” short forms, since I’m sure that many styles
derive their abbreviations from one of these three style guides.
Alternatively, we could stay with “long” and “short” and add a
"symbol" where a symbol exists, but we’ll need to determine what
terms to use when the three major styles conflict (e.g., no vs n). Ugh.

If citing with multiple locators (vol. 1, bk. IV, chap. II) is
sufficiently common, we may want to reconsider our approach. Or, we
could treat this as a fringe case. Even if we only support a single
locator, if the locator type is selectable, we already go farther
than EndNote.

Simon

6

Thanks for doing the research, John!

I bought a copy of Cite Right by Charles Lipson. A good variety and more
than a dozen styles summarized in one short book.

Given that many styles specify their own sets of abbreviations,

Recall that different style also have different ways, if at all, to shorten
“University Press.”

– John

7

Simon Kornblith wrote:

If citing with multiple locators (vol. 1, bk. IV, chap. II) is
sufficiently common, we may want to reconsider our approach.

I have seen books that use multiple locators; for example, a history
book that lists page and line numbers.

I suppose the more generic solution is to ditch the current locator
logic and just use macros?

I have no strong opinion; just rambling …

Bruce

8

Simon Kornblith wrote:

If citing with multiple locators (vol. 1, bk. IV, chap. II) is
sufficiently common, we may want to reconsider our approach.

I have seen books that use multiple locators; for example, a history
book that lists page and line numbers.

I suppose the more generic solution is to ditch the current locator
logic and just use macros?

I have no strong opinion; just rambling …

If we can come up with an acceptable way of implementing it, I’d be
happy to implement multiple locators. The problems are:

  1. Style authors shouldn’t have to specify how to format every single
    type of locator. As far as I can tell, we need the following options:

“page” | “line” | “paragraph” | “figure” | “note” | “number” | “opus”

“page” | “part” | “book” | “volume” | “verse” | “section” |
“chapter” | “other”

What if someone wants to provide special logic only for the first
three? This would appear to preclude using a simple “variable”
attribute.

  1. I’m not sure it’s actually going to get used enough to be worth
    the effort.

So, perhaps just add the locator conditional? It’s not ideal, but
it’s still much better than anything else out there.

Simon

9

If citing with multiple locators (vol. 1, bk. IV, chap. II) is
sufficiently common, we may want to reconsider our approach.

I have seen books that use multiple locators; for example, a history
book that lists page and line numbers.

I just finished a paper on ancient philosophy in which pages were the
locator in maybe 10% of the references. The paper will be published in a top
journal, according to their style guide. My citations were things like “§42”
for Cicero or “II 23, 68b12-3” for Aristotle. Another journal might have
wanted B23 68b12-13 for the same reference.

I can’t hope for CSL to handle all the potential variety and complexity
here. Just being able to enter these and not have the formatter stick a p.
or pp. in front of them (while still using p. and pp. etc., where
appropriate) would be enough.

John

10

“page” | “line” | “paragraph” | “figure” | “note” | “number” | “opus”

“page” | “part” | “book” | “volume” | “verse” | “section” |
“chapter” | “other”

If you go this route, I’d add “folio”, often abbreviated “f.”

11

I just thumbed through my dissertation and found this locator

f. A5r[p.5]-A8v[p.12]

That’s the back side of the fifth folio (also called a “leaf”) in the A
group of sheets bound together (the A “signature” or “quire”) through the
front side of the eighth folio in A, in other words, the pages that would
have been numbered 5 through 12 had the printer used page numbers.

(No, they weren’t all like that, thank goodness, although things like it,
usually without the bracketed numbers, are pretty common for citing early
printed books.)

Again, if CSL will just let me type it in and not mess it up, I’d be happy
enough.

John

From: John P. McCaskey [mailto:@John_P_McCaskey]
Sent: Wednesday, August 29, 2007 8:40 AM
To: ‘development discussion for xbiblio’
Subject: Re: [xbiblio-devel] Locators

If citing with multiple locators (vol. 1, bk. IV, chap. II) is
sufficiently common, we may want to reconsider our approach.

I have seen books that use multiple locators; for example, a history
book that lists page and line numbers.

I just finished a paper on ancient philosophy in which pages were the
locator in maybe 10% of the references. The paper will be published in a
top
journal, according to their style guide. My citations were things like
“§42”>-----Original Message-----

12

“page” | “line” | “paragraph” | “figure” | “note” | “number” | “opus”

“page” | “part” | “book” | “volume” | “verse” | “section” |
“chapter” | “other”

If you go this route, I’d add “folio”, often abbreviated “f.”

It seems to me that this would be a bit overkill. The UI you are
going to need to insert a citation as such into a text document will
become unwieldy quickly.

I’ve been doing some tinkering on what would be a workable UI on Mac
OS X. The second window will be a sheet on the first window. Locator
text can be edited by double clicking the cell. The upper table uses
a NSOutlineView because people usually like to sort their references
in groups.

Johan

13

With multiple locators, perhaps. With a single locator, one can just
select the locator type from a popup menu. The current (SVN) Zotero
UI looks like:

14

Simon Kornblith wrote:

It seems to me that this would be a bit overkill. The UI you are going
to need to insert a citation as such into a text document will become
unwieldy quickly.

With multiple locators, perhaps. With a single locator, one can just
select the locator type from a popup menu. The current (SVN) Zotero UI
looks like:

Which completely fails for multiple locators.

I see two options:

  1. user can click to add additional locators (as they do additional
    contributors in the main UI), using the same pop-up mechanism

  2. one of the pop-up options is a generic locator (for some of John’s
    funky things)

1 is the more forward-looking approach, though I personally could get by
with 2 (since I only typically use pages, and sometimes paragraphs).

Oh god, please no b and i buttons in Zotero!

Aside: I just about screamed yesterday when the latest upgrade to
Blackboard on campus added “rich text editing” by default. I had explain
to the one of the tech people how this was not only not helpful, it was
actually counter-productive.

Alas, getting off-topic …

Bruce

15

I see two options:

  1. user can click to add additional locators (as they do additional
    contributors in the main UI), using the same pop-up mechanism

  2. one of the pop-up options is a generic locator (for some of John’s
    funky things)

1 is the more forward-looking approach, though I personally could get by
with 2 (since I only typically use pages, and sometimes paragraphs).

I’m OK with 2 (though it would be nice if we can at least imagine how to
later extend to 1 at least in CSL if not a UI).

Should the generic label on the pop-up be blank or “other”? A blank offer no
explanation. The word “other” might suggest the word or its abbreviation is
going to appear in the citation. How about “[other]” or “(other)”?

John

16

I’ve been playing around with the various options for dealing with
locators. My conclusion is that the most logical (but somewhat
hackish) way of dealing with these issues is that, given:

we will add the period as a suffix only if the used locator is really
of form=“short”. This means that, for things like “line” that have
only a long form, no period will be added. If a style needs a
different term than is defined in locales.xml for that form, they can
use in the CSL to define it. To deal with symbols, we need:

Symbols are used if they exist, then short forms, then long forms.
Again, only short forms have periods.

I’ll probably throw in a locator conditional, because there are a few
use cases I can think of, but usually it should be unnecessary.

Are there any objections to this? I really need to get this done
soon. I have far more important things to be spending my time on.

Simon

17

Simon Kornblith wrote:

Are there any objections to this?

None here.

Bruce