Expand number of locator terms

[rmzelle]

See http://forums.zotero.org/discussion/14717/universal-locator-type/

In addition to just expanding the number of locator terms, we could also add an empty-string locator type, so that the user can store the label in the locator variable field.

Regardless of the solution chosen, we probably should make an inventory of missing locator types.

Identified so far:
Plays: Act I, scene i, lines 12-23 (or act, scene, verse)
Ancient sources: Book 1, lines 1-8; Book 6, chapters 57‐58
Bibles: Psalm 86:5; 1 Cor. 13:1 New International Version (Book Chapter:Verse, Translation)
Legal: article

http://www.longwoodshakespeare.org/quoteverse.html
http://blog.apastyle.org/apastyle/2009/12/happy-holiday-citing-citation-of-classical-works.html
http://www.skidmore.edu/classics/courses/2006fall/ssp100/citations.pdf

---

See also the discussion at http://xbiblio-devel.2463403.n2.nabble.com/Improving-support-for-locators-td7578007.html

[bdarcus]

Minor issue:

{ "label": "none", "locator": "Act I, scene i, lines 12-23" }

First point is this is easier as just:

{ "locator": "Act I, scene i, lines 12-23" }.

E.g. just make the label key optional.

The second point is more about the substance of the proposal. If I understand right, we have two, completely orthogonal, issues here.

1. custom locators (what to do about point locator labels we haven't itemized?)
2. multiple locators

This proposal (as represented in the example above; it's doesn't seem to be formalized as such) attempts to solve both problems at once, so that the upshot is that the second problem requires a free text value.

For sake of argument, why not split these issues, so that you have a point locator defined as a list of key values; something like?

[
  { "act": "1"},
  { "scene": "3"},
  { "value": "foo 5"}
]

[rmzelle]

@bdarcus, with regard to making the "label" field optional: yes, I already realized yesterday that that would be a cleaner solution.

With regard to storing hierarchical locators in a structured way: this is obviously preferred from a data perspective, but wouldn't this require a lot of enhancements to CSL, CSL processors and CSL applications? How are we going to deal with the delimiters between these locator elements? Do users have to enter the locator elements in separate fields, or should the CSL processor try to parse the field (and what happens if the parsing fails?). I don't mind revisiting this later, but having a no-label locator value seems like a very effective stopgap measure for CSL 1.0.1.

[bdarcus]

How are processors supposed to deal with this now (with this
proposal)? They simply don't process the value unless there's a
locator type?

[rmzelle]

That's my understanding, yes. @fbennett, that's what you're thinking too, right?

[denismaier]

Anyone knows where we are here? @bdarcus @bwiernik ? We have added some additional locator variables in #201, but not those mentioned here. Also: We haven't considered multiple locators yet, right?

[bwiernik]

Multiple locators we considered—they can be entered as a comma delimited list with the supplying labels or their abbreviations indicating a change in type (same as we discussed with page). I haven’t had a chance to prepare a PR for that.

Given that we are doing that, I agree with making the label key optional (if there, it applies to the first locator in the list if it doesn’t have a label).

act, scene, line, and verse sound good for adding. Didn’t think of those.

For biblical verses and the like, that could be handled with a label-less locator or a citation suffix. “Psalms” isn’t a locator label, but part of the value.

[bdarcus]

If I haven't mentioned it already, do look at how pandoc does this.

[denismaier]

act, scene, line, and verse sound good for adding. Didn’t think of those.

So we have to add act and scene. Line and verse are already there.

[bwiernik]

If I haven't mentioned it already, do look at how pandoc does this.

https://github.com/jgm/pandoc-citeproc/blob/b05d286b15b3545faf477301267e1a12be192e87/src/Text/CSL/Pandoc.hs#L472

It supports a few syntaxes, one of which matching what I was describing.

[bdarcus]

Also: https://github.com/jgm/pandoc-website/blob/master/MANUAL.txt#L4800

[bwiernik]

Thanks.

@jgm Question about the delimited syntax for locators: https://github.com/jgm/pandoc-citeproc/blob/b05d286b15b3545faf477301267e1a12be192e87/src/Text/CSL/Pandoc.hs#L485

If a user wanted to cite Psalms 2:1–3 as a locator, rather than a suffix, would they need to use this syntax:
[@KJV, {Psalms 2:1–3}]

or would this work:
[@KJV, Psalms 2:1–3]

The one would be interpreted as a suffix, correct?

[jgm]

I believe that's right. I haven't actually used this feature myself, nor did I develop it.

[denismaier]

This should be partly solved. But we haven't added a universal string locator type. Would there be some value in adding this?

[denismaier]

This should be partly solved. But we haven't added a universal string locator type. Would there be some value in adding this?

If not, I suggest we close this for now and open new (more focused) locator related issues when we have specific demands.

[denismaier]

Concerning universal string locator types:
Con: users who want this can already just use a suffix for adding this kind of information.
Pro: with suffixes you don't have access to style specific number range formatting.