Multiple locators would also be useful for citing multivolume
collections–i.e. in a citation below locators are volume 3, page 25.
Luigi Albertini, The Origins of the War of 1914, trans. Isabella
Massey (New York, NY: Enigma Books, 2005), 3:25.
Is there an existing style that does this correctly?
Thanks,
Elena
Elena Razlogova wrote:
Multiple locators would also be useful for citing multivolume
collections–i.e. in a citation below locators are volume 3, page 25.Luigi Albertini, The Origins of the War of 1914, trans. Isabella
Massey (New York, NY: Enigma Books, 2005), 3:25.Is there an existing style that does this correctly?
AFAIK, no.
The typical way this is handled currently assumes one point citation
locator. This isn’t really very good.
I think with some hindsight and the subsequent adding of the macro
functionality, the correct may to handle this is to probably to use a
macro and explicitly layout the locators, such that whee constructing a
citation style, you just do:
<text macro="point-locators"/>
I’m happy to discuss this change, but we need to give it some thought,
and make sure to fix a problem that’s already present in Zotero, and
which got brought over to CSL: the ambiguity of locators (pages, etc.)
within a cited item (the cited pages, etc.) vs. those that locate the
item within some larger collection.
BTW, I’ve been working on a web application for storing and creating CSL
styles. I don’t yet have anything to show, but the basic models includes
classes like:
Style
Context (citation or bibliography)
Macro
So, for example, a macro object/row will contain the XML fragment for
that chunk, in turn validated against the CSL schema.
The idea is to incrementally build up the pieces that make up styles
around macros, and to make it easy to select them.
The above use case would be a good example of how this would work.
Bruce
Elena Razlogova wrote:
Multiple locators would also be useful for citing multivolume
collections–i.e. in a citation below locators are volume 3, page 25.Luigi Albertini, The Origins of the War of 1914, trans. Isabella
Massey (New York, NY: Enigma Books, 2005), 3:25.Is there an existing style that does this correctly?
Thanks,
Elena
I don’t know if there is an existing style…
It would be very usefull a possibility for test locators type, for
putting them at the end (pages), or after the title (sources of ancient
philosophy).
Thanks,
Nicolae
Elena Razlogova wrote:
Multiple locators would also be useful for citing multivolume
collections–i.e. in a citation below locators are volume 3, page 25.Luigi Albertini, The Origins of the War of 1914, trans. Isabella
Massey (New York, NY: Enigma Books, 2005), 3:25.Is there an existing style that does this correctly?
I think with some hindsight and the subsequent adding of the macro
functionality, the correct may to handle this is to probably to use a
macro and explicitly layout the locators, such that whee
constructing a
citation style, you just do:
Can we make this possible (this seems simpler than nicolae’s
suggestion of conditionals based on locator type):
I’m happy to discuss this change, but we need to give it some thought,
and make sure to fix a problem that’s already present in Zotero, and
which got brought over to CSL: the ambiguity of locators (pages, etc.)
within a cited item (the cited pages, etc.) vs. those that locate the
item within some larger collection.
Not sure what you mean here.
Thanks,
Elena
I’m not opposed to this, but what happens if the user tries to cite a
locator type that the style doesn’t specify how to format? Or should
Zotero only show locator types for which the selected style has a
element?
Simon
Can we make this possible (this seems simpler than nicolae’s
suggestion of conditionals based on locator type):I’m not opposed to this, but what happens if the user tries to cite a
locator type that the style doesn’t specify how to format? Or should
Zotero only show locator types for which the selected style has a
element?
I think most locators (except maybe pages) need a term or a particular
place in citation defined to be cited correctly, so if we don’t cite
locators unless specified we won’t lose much.
Elena
forgot to reply-all …
…
Can we make this possible (this seems simpler than nicolae’s suggestion of
conditionals based on locator type):
Are you asking if we can get rid of the cs:label element in favor of a
an attribute on the cs:text element?
What I was trying to emphasize in this example is that a volume and an
issue are not point locators, but which I mean specific locations
within a cited item.
I’m also highlighting that there’s a bug in Zotero’s design that has
made its way into CSL, and that is that it’s unclear what “page”
means. Does it mean the numbers of pages in a book (as it does in
Zotero)? Does it mean the page range of a chapter within a book (as it
also does in Zotero)? Or does it mean the specific page from which I’m
extracting a quote (what I mean by a point locator)?
I’m happy to discuss this change, but we need to give it some thought,
and make sure to fix a problem that’s already present in Zotero, and
which got brought over to CSL: the ambiguity of locators (pages, etc.)
within a cited item (the cited pages, etc.) vs. those that locate the
item within some larger collection.Not sure what you mean here.
See above.
Bruce
Are you asking if we can get rid of the cs:label element in favor of a
an attribute on the cs:text element?
Can we have both?
What I was trying to emphasize in this example is that a volume and an
issue are not point locators, but which I mean specific locations
within a cited item.
A volume number entered by the user when citing a multivolume work
seems like a point-locator to me:
I think it would be easiest to assume that any locator entered by the
user is a point-locator, whereas any locator passed from Zotero is a
“regular” locator.
I’m also highlighting that there’s a bug in Zotero’s design that has
made its way into CSL, and that is that it’s unclear what “page”
means. Does it mean the numbers of pages in a book (as it does in
Zotero)? Does it mean the page range of a chapter within a book (as it
also does in Zotero)?
There is a plan to resolve this:
https://www.zotero.org/trac/ticket/786
Or does it mean the specific page from which I’m
extracting a quote (what I mean by a point locator)?
Pages don’t seem to be any different in this respect than any other
locator defined in CSL–issue, section, volume, etc.–each of these
can be passed from Zotero or entered by the user. We could enter
variable=“page” if it’s a Zotero value, and locator=“page” if it’s the
user’s value, to distinguish between the two.
Elena
Are you asking if we can get rid of the cs:label element in favor of a
an attribute on the cs:text element?Can we have both?
Why?
What I was trying to emphasize in this example is that a volume and an
issue are not point locators, but which I mean specific locations
within a cited item.A volume number entered by the user when citing a multivolume work
seems like a point-locator to me:
Hmm … I guess one might argue that, except that neither Zotero, nor
CSL, nor any other implementation I’m aware of really has any notion
of sub-document/item content. We don’t have a type for “Page” or
“Fragment”, for example. So we cite the whole object, and add a
parameters that specifies the specific context within it.
…
Pages don’t seem to be any different in this respect than any other
locator defined in CSL–issue, section, volume, etc.–each of these
can be passed from Zotero or entered by the user. We could enter
variable=“page” if it’s a Zotero value, and locator=“page” if it’s the
user’s value, to distinguish between the two.
That might work. Simon? Julian? Any opinions on this?
Bruce
Pages don’t seem to be any different in this respect than any other
locator defined in CSL–issue, section, volume, etc.–each of these
can be passed from Zotero or entered by the user. We could enter
variable=“page” if it’s a Zotero value, and locator=“page” if it’s
the
user’s value, to distinguish between the two.That might work. Simon? Julian? Any opinions on this?
Bruce
In the interest of moving things along, Simon had posted on this
earlier:
argh … forgot again …---------- Forwarded message ----------
From: Bruce D’Arcus <@Bruce_D_Arcus1>
Date: Thu, Feb 21, 2008 at 5:31 PM
Subject: Re: [xbiblio-devel] locators
To: zotero-dev@googlegroups.com
On Thu, Feb 21, 2008 at 5:00 PM, Elena Razlogova <@Elena_Razlogova> wrote:
In the interest of moving things along, Simon had posted on this
earlier:On Feb 19, 2008, at 12:42 PM, Simon Kornblith wrote:
I’m not opposed to this, but what happens if the user tries to cite a
locator type that the style doesn’t specify how to format? Or should
Zotero only show locator types for which the selected style has a
element?I think most locators (except maybe pages) need a term or a
particular place in citation defined to be cited correctly, so if we
don’t cite locators unless specified we won’t lose much.
I’ve got about 10 things I’m juggling ATM, and it’s felt like a long
day, so forgive me
if I’ve lost this discussion.
IIRC, this started with a desire for more complex markup of point
citation details; being
able to specify, for example “page 3, paragraph 2” and such.
This then led to recognition of some ambiguity between user-supplied,
context-specific
locators on the one hand (page 23 of this article), and generic
locators that belong to the
data record per se (pages 20-45 as the page range for an article
within an issue).
So IIRC, Elena, you were proposing adding a “locator” attribute, which
I was thinking would
make the cs:locator element redundant. Your response (“can we have
both”) suggested
perhaps not, but I ended up confused.
It might help for those us that are being a bit dim if you could
summarize your suggestion
with a quick “we need a, b, c because x, y, z.”
Aside: I have a feeling that using “locator” to refer to the first
case will be confusing. It is for
me at least.
Bruce
IIRC, this started with a desire for more complex markup of point
citation details; being
able to specify, for example “page 3, paragraph 2” and such.
yes
This then led to recognition of some ambiguity between user-supplied,
context-specific
locators on the one hand (page 23 of this article), and generic
locators that belong to the
data record per se (pages 20-45 as the page range for an article
within an issue).
yesSo IIRC, Elena, you were proposing adding a “locator” attribute, which
I was thinking would
make the cs:locator element redundant. Your response (“can we have
both”) suggested
perhaps not, but I ended up confused.
actually, you had asked:
Are you asking if we can get rid of the cs:label element in favor
of a
an attribute on the cs:text element?
We’d still need labels to add terms (“p”, “pp”, etc) to locators added
by the user. We won’t need the variable “locator”–is that what you’re
asking?
It might help for those us that are being a bit dim if you could
summarize your suggestion
with a quick “we need a, b, c because x, y, z.”
you summarize everything nicely above
Aside: I have a feeling that using “locator” to refer to the first
case will be confusing.
point-locator then
I’ve got about 10 things I’m juggling ATM
me too
Elena> It is for
Sorry I keep losing this thread …
Elena Razlogova wrote:
…
So IIRC, Elena, you were proposing adding a “locator” attribute, which
I was thinking would
make the cs:locator element redundant. Your response (“can we have
both”) suggested
perhaps not, but I ended up confused.actually, you had asked:
Are you asking if we can get rid of the cs:label element in favor
of a
an attribute on the cs:text element?We’d still need labels to add terms (“p”, “pp”, etc) to locators added
by the user. We won’t need the variable “locator”–is that what you’re
asking?
Ah, my bad.
So now we have something like:
This is nice and concise (no need to explicitly account for each kind of
locator), but breaks down if you need to do multiple. The question is
how to get the best of both worlds? I’m actually a little stuck on this.
In other words, what exactly would you be adding to the Chicago style,
say, to get the effect you’d like to achieve?
Bruce
So now we have something like:
This doesn’t work for Chicago with the current “one locator” setup
anyway, because every locator requires a label except page. Because
page is the most common locator I have to exclude the label and all
other locators are cited incorrectly.
This is nice and concise (no need to explicitly account for each
kind of
locator), but breaks down if you need to do multiple. The question is
how to get the best of both worlds? I’m actually a little stuck on
this.In other words, what exactly would you be adding to the Chicago style,
say, to get the effect you’d like to achieve?
Using previous examples, with this macro:
Will let you cite both of these (with locators volume 3, page 25):
Luigi Albertini, The Origins of the War of 1914, trans. Isabella
Massey (New York, NY: Enigma Books, 2005), vol. 3.
Luigi Albertini, The Origins of the War of 1914, trans. Isabella
Massey (New York, NY: Enigma Books, 2005), 3:25.
or, in Nicolae’s example, the following macros (with locators book IX,
chapter III, paragraph 2, page 50-52):
Will let you cite both of these:
Herodot, History, IX, III, 2, edition by…, Place, 2007.
Turcan, /Title about Herodot/, Bucharest, Humanitas Publisher, 2008,
pp. 50-52.
In theory, we could keep locator variables and have something like
this to make sure all locators get cited:
Any of the above will require complicated conditionals but I don’t see
how that can be avoided.
Best,
Elena
Barring a Zotero bug, the following should work:
Simon
So now we have something like:
This doesn’t work for Chicago with the current “one locator” setup
anyway, because every locator requires a label except page. Because
page is the most common locator I have to exclude the label and all
other locators are cited incorrectly.Barring a Zotero bug, the following should work:
Thanks! I didn’t know this was supposed to work. There is indeed a bug
however:
I tried this:
<group prefix=", ">
<choose>
<if locator="page" match="none">
<label variable="locator" form="short" suffix=". "/>
</if>
</choose>
<text variable="locator"/>
</group>
And got this error (and no label):
Error: citation is not defined
Source File: chrome://zotero/content/xpcom/cite.js
Line: 1313
I created a ticket.
Best,
Elena
OK …
Elena Razlogova wrote:
Using previous examples, with this macro:
So looking at the schema, we currently have within the conditional
pattern this:
## A conditional on the locator for this specific entry
attribute locator { cs-terms.locator }?,
So it can’t be referenced outside that context.
We thus need to create a “locator” pattern so that it can be reused in
cs:text.
We also need to make sure to document it correctly in the different
contexts.
So would this work?
generic pattern:
locator.attribute = attribute locator { cs-terms.locator }?,
change conditional to use this pattern:
locator?,
add pattern to text:
This is more complex, but I’ll work it out. I just need some
documentation that will unambiguously explain how this would work, and
which works across style classes (number, author-date, etc.).
Finally, a question that goes this issue of definition:
What becomes the difference between this:
<cs:text variable=“volume”/>
… and:
<cs:text locator=“volume”/>
…? Do we remove the locators values as option for “variable”?
Bruce
So looking at the schema, we currently have within the conditional
pattern this:## A conditional on the locator for this specific entry attribute locator { cs-terms.locator }?,So it can’t be referenced outside that context.
We thus need to create a “locator” pattern so that it can be reused in
cs:text.We also need to make sure to document it correctly in the different
contexts.So would this work?
generic pattern:
[insert documentation]
locator.attribute = attribute locator { cs-terms.locator }?,
change conditional to use this pattern:
A conditional on the locator for this specific entry
locator?,
add pattern to text:
This is more complex, but I’ll work it out. I just need some
documentation that will unambiguously explain how this would work, and
which works across style classes (number, author-date, etc.).
Sounds fine to me.
Finally, a question that goes this issue of definition:
What becomes the difference between this:
<cs:text variable=“volume”/>
… and:
<cs:text locator=“volume”/>
…? Do we remove the locators values as option for “variable”?
It seems like the former should show up in the bibliography as
information about the source, whereas the latter would be a “point
locator” as we’ve been calling them and show up in the citation.
Simon
So looking at the schema, we currently have within the conditional
pattern this:A conditional on the locator for this specific entry
attribute locator { cs-terms.locator }?,
So it can’t be referenced outside that context.
We thus need to create a “locator” pattern so that it can be reused
in
cs:text.We also need to make sure to document it correctly in the different
contexts.So would this work?
generic pattern:
[insert documentation]
locator.attribute = attribute locator { cs-terms.locator }?,
change conditional to use this pattern:
A conditional on the locator for this specific entry
locator?,
add pattern to text:
This is more complex, but I’ll work it out. I just need some
documentation that will unambiguously explain how this would work,
and
which works across style classes (number, author-date, etc.).Sounds fine to me.
Finally, a question that goes this issue of definition:
What becomes the difference between this:
<cs:text variable=“volume”/>
… and:
<cs:text locator=“volume”/>
…? Do we remove the locators values as option for “variable”?
It seems like the former should show up in the bibliography as
information about the source, whereas the latter would be a “point
locator” as we’ve been calling them and show up in the citation.
Yes, we need both. Variables would also show up in a citation, in a
different place than locators:
variable:
John Donne, The Variorum Edition of the Poetry of John Donne, ed.
Gary A. Stringer, vol. 6 (Bloomington: Indiana University Press,
1995), 5
locator:
John Donne, The Variorum Edition of the Poetry of John Donne, ed. Gary
A. Stringer (Bloomington: Indiana University Press, 1995), vol. 6.
Elena
Elena Razlogova wrote:
…
…? Do we remove the locators values as option for “variable”?
It seems like the former should show up in the bibliography as
information about the source, whereas the latter would be a “point
locator” as we’ve been calling them and show up in the citation.Yes, we need both. Variables would also show up in a citation, in a
different place than locators:
We need to make this distinction more clear. Your first case is still a
locator.
Maybe:
point-locator.att = attribute point-locator { cs-terms.locator }
We then leave cs:text@variable alone I guess.
Bruce