some general observations, and an issue or two for Simon below …
First issue is, any objection to me splitting the terms and types lists
into separate – more easily maintained – schemas?
Moving on …
Elena Razlogova wrote:
Hi Bruce and Simon–
I looked at the new CSL files here:
#632 (Add Citation Formats) – Zotero
And it looks like none of these are set up for citing archival
sources (manuscripts, letters, interviews) or even presentations. I
tried to add these to the existing CSLs, but it doesn’t seem to be
possible right now.CSL schema does include such cs-types as “interview,” “manuscript,”
and “personal_communication”. At the same time it looks like the
schema doesn’t define “recipient,” “interviewer,” “location in
archive,” and “repository” (or whatever you wish to call these in
CSL)–all variables necessary to cite these types correctly. (“Type”
for manuscripts and letters and “Medium” for interviews are also
necessary in some cases).XBib download | SourceForge.net
csl.rnc?view=markup
Bruce, can you add these variables? A style that only cites books,
articles, and theses is not complete. Even Endnote can do better.
I’ve explained more than once that types are de-emphasized in CSL, and
that the core types – article, book, and chapter – serve also as
generic fallbacks.
The reason they are de-emphasized so that formatting can work for
particular types of resources even in the absence of explicit
definitions for them; e.g. so that a formatting engine does not break
when encountering the diversity of sources out there in the wild.
So with that out of the way, clearly the attributes or properties are
critical to be able to capture. So let me take one of the styles Julian
posted and see if I can find a better way (if these were in a publicly
accessible repository, I would edit them directly of course, but since
they’re not …).
Let’s focus on the chicago note example.
On the citation, I think this is wrong:
<else-if type="chapter book">
<group class="container" prefix=". ">
<text term="in" text-transform="lowercase"/>
<text variable="container-title" font-style="italic"
prefix=" " suffix=“,”/>
Should only have a type of “chapter”; right?
On the bibliography:
<layout suffix=".">
<text macro="author" suffix="."/>
<choose>
Good: you use a richly defined author macro that applies to all types of
resources.
Bad: is that the ONLY formatting that is so general? What about “title”?
But to solve Elena’s examples, I’d suggest we need:
-
a “medium” variable. Already there.
-
I can indeed add “interviewer” and “recipient”
-
Archival documents. Here’s two examples from Chicago:
Alvin Johnson, memorandum, 1937, file 36, Horace Kellen Papers, YIYO
Institute, New York.
James Oglethorpe to the Trustees, 13 January 1733, Phillips Collection
of Egmont Manuscripts, 14200:13, University of Georgia Library.
So we’ve got:
- authors
- probably a plain text description or note (though I would store
“memorandum” as a title ATM)
- a recipient
- dates
- locators
- collection titles
- archive and location.
[Oh, and BTW, there are online archives these days, which will become
increasingly common, so one could imagine URLs too.]
So one could do something simple like this:
<text macro="author" suffix=" "/>
<group>
<text term="to" text-transform="lowercase" suffix=" "/>
<names variable="recipient"/>
</group>
<text macro="title"/> <!-- perhaps here the macro falls back to
“note”? →
So we’re exploiting macros, and we are not using types.
With the group around recipient, IIRC, the formatting rules would say
the text “to” would only get printed if the recipient variable was
present. Is that your understanding Simon? If yes, we need to document
that in the schema.
As I’m suggesting, the title macro might well contain logic that falls
back to the note if the title is not present (though I’m avoiding media
issues here). If there’s no note, nothing gets printed (as in the second
example; unless of course, one encodes that information in the title,
which I often do).
The only thing we’re really missing above is the archive and its
location. Unless I’m missing something obvious, I guess we probably do
need to add a couple of variables. I suggest they mirror “publisher” and
“publisher-place”. The obvious option is “archive.”
But is that too specific? What about those cases where, say, an
individual holds a copy of an item? That might suggest a more generic
“owner” or “holder”? Or maybe that’s orthogonal.
- note to Simon: I’m finding myself confused by the “page” variable. It
sounds awkward for page ranges, and I’m not clear now how cited pages fit.
Bruce