I would like to have a "# of pages" field in the Report type. To me, reports are more like (large) leaflets or (little) books, so "# of pages" makes more sense than "pages" (the latter implying that the report is a sub-section of what?). I don't care whether "pages" is available or not though, I would just like to have "# of pages" available.
Note that I use the Report type for working/discussion papers as also has been advised elsewhere in this forum.
See for examples:
http://www.eurofound.europa.eu/pubdocs/2010/60/en/1/EF1060EN.pdf
http://dx.doi.org/10.1787/5kg9q0nmbws8-en
http://ftp.iza.org/dp5785.pdf

See also this thread.

absolutely yes to # of pages - the question is if we want to keep the pages field for reports- I'm inclined to say no - lets just go with replacing "pages" by "# of pages".

What specifically is unsatisfactory about Document and Presentation? What information would you like to include?

If you mean ISBN, then they're planned for Thesis and Report in the next revision of the item fields.

For connecting items there is the "related" function. For organizational purposes there are tags. Please refer to the first post in this thread for some of the considerations that go into creating new item types.

Dear colleagues,

as for the item types, what I miss at most is:

1. (Conference) Proceedings

If one needs to catalogue proceedings "as a whole", one has to use a workaround and apply "Conference Paper" or "Book". Neither of these possibilities is satisfactory enough. I would suggest creating of a new item type, which would have a similar relation to "Conference Paper" as "Book" has to "Book Section". (If you know JabRef you might guess what I have in mind.)

2. Working Paper

This is a standard type of academic work. Again, it is possible to use a workaround and apply "Document", but the "compatibility" is not full. Especially, "#Pages" and "Series" are missing. Many times "Working Paper" has got a specific "Number" (such in case of Kellog Institute, for instance) and/or "Version". Also, I would prefer to have "University" or "Institution" field intead of "Publisher", but of course this is disputable.

3. Lecture

Again, one can use "Presentation" instead, but in such case, there are important fields absent: "Institution", "(Lecture) Series", "#Pages" (in case it is a transcript), "Length" or "Duration" (in case it is a recording). There is also a redundant, and perhaps even misleading field: "Meeting Name" (of course, I understand it is an important field for a "Presentation", but not for a "Lecture"). Thus, I suggest creating a new item type in this case as well.

As for the fields of already existing item types, I would more than welcome several changes:

1. Book

I very much miss "Introduction Author" and "Foreword Author" fields. These are not the same as "Contributor", in my opinion. I would also appreciate if "Title" was accompanied by "Secondary Title" (at present one has to write both primary and secondary title in the same field, which makes the entry too long sometimes).

2. Newspaper Article

Many times one has to use "Magazine Article" for newspaper articles, as there are no "Volume" and "Issue" fields to be filled in case of the "Newspaper Article" item type.

3. TV Broadcast

There are no "Anchorman" and/or "Interviewer" fields. Predominantly, it is much more difficult to find out who the producer, director or scriptwriter is. Thus, the suggested fields would very much help to identify the item properly.

4. Video Recording

In this case, one has difficulties to fill in who the "Publisher" is, or which "Institution" has issued the video record.

Thanks to anybody taking notice of my post.

Regards
JR

Dear Avram,

Thanks for your reply. I am glad for the possibility to discuss these things.

ITEMS
Ad 1. (Conference) Proceedings

What precisely do you need in such a type that you don't have in the type "Book"?... ...Personally, I've found "Book" to work rather well...

Of course, I use "Book" item for "Proceedings". However, I am missing there

• "Institution" or "University" to fill in, who organised the conference,


• "(Conference) Place", where the conference actually took place,


• "(Conference) Date", when the conference actually took place.

Many times the last two entries are different from "Place" and "Date" of the published proceedings.

Ad 2. Working Paper

Isn't this just "Report"? What is it missing?

I agree "Report" is more suitable than "Document". Nevertheless, in my opinion, the basic catalogue items should not be intermingled: "Report" is simply not "Working Paper". According to this logic, we could say there is no difference between "Journal Article" and "Blog Post", or between "Thesis" and "Manuscript", or between "Encyclopedia Article" and "Dictionary Entry", or between "Presentation" and "Conference Paper". I understand one can use tags, "Report Type" or "Extra" field, to make a workaround. However, I do not consider it satisfactory. Moreover, there are still missing fields I have already mentioned:

• "#Pages"


• "Version"

Ad 3. Lecture

I think that presentation will work... ...I usually tack it onto "Meeting Name" or "Place". I use "Meeting Name" essentially as "Series"...

My argument against "presentation will work" is the same as in the case of mixing "Report" and "Working Paper". Of course, I use the "Meeting Name" for "Series" too (and in the "Type" field I fill in "Lecture"). Still I hope for more.

FIELDS
Ad 1. Book

"Introduction Author" and "Foreword Author": How do you expect these to appear in citations?

Actually, I do not. My "problem" might be that I use Zotero as a personal library catalogue, so I try to put all the standard data in (as in standard library catalogue), which sometimes means more data than the required minimum for citations. That is the very case of "Introduction Author" and "Foreword Author". Again, one can use tags, but it is a workaround.

The Title/Secondary Title is usually handled by putting both in Title and just the primary title in Short Title.

I agree. I have not realised that possibility. Thanks for edifying me.

Ad 2. Newspaper Article

"Volume" and "Issue" should be on their way.

Great to hear. Thanks.

Ad 3. TV Broadcast

Perhaps not "Anchorman" and/or "Interviewer", but just "Correspondent"?

"Correspondent" would be fine, but he or she is not always responsible for authorship (it may be a "Reporter" behind the scenes). In case of TV news interview, I think "Interviewer" or "Anchor" is at least co-reponsible for authorship, as he or she is the one who actually asks questions (often he or she also prepares them). So, I would vote for the possibility to mention them. And how would you classify a journalist who invites two or three experts to discuss a current topic? A "Host" perhaps?

4. Video Recording

Note that you're under no obligation to use all the fields!

Indeed, I am not. However, I have referred to the case when one needed to fill in "Institution" and/or "Publisher", and there were no such fields.

Regards
JR

no it shouldn't. Please refer to the first post for a description of how types are used and decided on. E.g. the distinction between manuscript and published source is perfectly sensible for a library, but not necessarily for a reference manager.

How are such supplements cited? If they're cited as monographs, I would treat them as books in Zotero and put that data in the Series fields. An uncontrolled proliferation of types would make citation styles nigh impossible to create, and would make it hard for most people without a background in cataloging to work effectively with Zotero.

Generally we're now conflating two issues:
1. Should Zotero adopt the LOC list - which I think it clearly shouldn't. There are things on the list that Zotero shouldn't worry about (e.g. manuscript vs. published, archival material as separate item type etc.) as item types and others where it needs to be more fine grained (e.g. legal citations, different types of archival material, reports/working papers etc.).

2. Should Zotero have a periodical item type? That's not the first time this is being requested, someone would have to dig up the old discussions, which, I believe, were mainly from French scholars.
I don't have a strong opinion on this either way. That said, DOI is scheduled to be added to all item types:
https://github.com/ajlyon/zotero-bits/issues/1
as is ISSN:
https://github.com/ajlyon/zotero-bits/issues/4
pages wouldn't be needed for a monograph, and if I understand correctly Publication and Issue would be the equivalent of Series and Series #.

That's great.

Adding DOI and ISSN to types will be a big help. I would not drop the pages requirement, however, as some Supplements provide numbers in their citations. Sometimes the numbering is separate, as for a monograph, and other times it is a continuation of the page numbers in the main publication, or a switch to Roman numerals.

For Legal case / case law,bill and statute,

We need fields :
- Series (Reports often have a serie)
- Report-year
- Place

Example
Chaoulli c. Québec (Procureur général), 2005 CSC 35, [2005] 1 RCS (8e) 791 (C.S.C. C.A.) juge en Chef McLachhlin [additionnal information/short-title for hereinafter].

Example --> Information type / Field: XY
Chaoulli c. Québec (Procureur général), --> Field: Title
2005 --> Date of the decision / Field: date
CSC --> Field: Authority
35, --> Field: Number
[2005] --> Year of the report/binder/paper publication --> *Missing field*
1 --> Volume# / Field: issue
RCS --> Report/binder/book // Field: Countainer-title
(8e) --> Series of the report / *Missing field*
791 --> First page / Field: page
(C.S.C. --> Recurrent authority / (Okay, already there)
CA.) --> Geographic indication (province, country) / *Missing field*
juge en Chef McLachhlin --> Using author...
[additionnal information/short-title for hereinafter]. --> Shorrt-title for short-title, and additionnal information goes in the field: extra. However, we're also using the extra field to discriminate for more than 20+ citing styles of jurisdiction. So *Missing a field* for additionnal information like... dicident decision.

It is very awkward to use the style with all those missing fields.
Notice that the geographic indication (place) misses for bill/statute too, as well as the year of the report and serie.

Philippe is a contributor to the CitationStyles.org project, and has generously offered up a comprehensive study of 20 legal styles that I've received, but haven't yet examined. As our two branches of analysis converge, we'll be putting forward a definite proposal; as the issues he raises show, we'll be hankering after some substantial changes in the legal types.

(As one comment on the suggestions posted above, we might want "judge" as a discrete creator type. There are "case notes" in both civil and common law jurisdictions which are most comfortably entered as "legal_case" because they require much of the same metadata, and (in French citation) collapse as parallel references when cited together with a case. Case notes and judgments can require different formatting and are different categories, though, so having two separate creator types would be useful.)

Christian - no need to re-post things that are already listed on the whiteboard (and issue tracker)
https://github.com/ajlyon/zotero-bits/wiki/Zotero-types-whiteboard

@adamsmith & ajlyon: sorry! ;-) I had seen ISSN in issue discussion only in the Zotero-fields thesis and book (and mapping to CSL-ISSN); but no general mapping of Zotero-ISSN to CSL-ISSN and even in the issue tracker I could not find a mapping involving ISSN. Hope this is included / logical then? Is this the best place to add a comment: https://github.com/ajlyon/zotero-bits/issues/4 ?

Another question to versions / roadmap:
v 2.1.10: actual release (2 Sep 2011)
v 3.0: actual Beta Release (22 Aug 2011)
v 3.1+: here discussed changes to fields and item types

I understand that the integration of CSL-features and beta-testing is complex, but a possible prediction would be very helpful. Is there a status of the 3.0 Beta and a plan when 3.1 would be beta?

opened an issue to add illustrator as creator type:
https://github.com/ajlyon/zotero-bits/issues/47

ketchell - please read the first post in this thread wrt adding fields - fields are primarily for storing bibliographic information, i.e. the type of information that may be used to cite the item in question.
For everything else use note, tags etc.
If GPS coordinates are actually cited for maps, please also see the first post and provide documentation.

Please add support for subtitles of books (http://forums.zotero.org/discussion/8077/separate-fields-for-title-and-subtitle/).

I'm currently making the Zotero format for the Pontifical Biblical Institute. They require that a book title be formatted in italics, while the book subtitle be formatted in regular type. Both fields are considered required.

Documentation of the style used at the Pontifical Biblical Institute can be found in "A Guide to Biblical Research" by Stanislaw Bazylinski (http://www.biblico.it/pubblicazioni/sb36_bazylinski_engl.htm).

javima, christof:
http://gsl-nagoya-u.net/http/pub/zotero-multilingual-overview.html

The Multilingual version, as I understand it, will eventually be folded back into Zotero. I'm not sure if there's much willingness to implement half-baked solutions until then, though I can certainly see why such a field would be useful.
edit: add this here:
https://github.com/ajlyon/zotero-bits/issues/13

I'll take all the endorsements I can get. :)

Re the original title etc requested by javimat and christof.s, this is an interesting wrinkle. The use cases that MLZ addresses are typically works in a language unfamiliar to (a portion of) the readership, and so call for a supplementary translation against the title, and transliteration of scripts that might otherwise be frightening or otherwise off-putting to (a portion of) the audience.

Here, the call is for the reverse -- the work and its citation details are already in a familiar language, but the original is to be provided for reference. To cope with this, we would want to be able to mix the two forms of reference in a document. I think that can be done smoothly, without changes to the existing UI, by assuring that the original-language titles of (say) Russian works are never pulled in as "translations" when (say) "ru" is selected as a translation language.

While that adjustment to the logic in MLZ would be a good thing (and so thanks for raising the issue!), I'm not sure this use case should be covered by multilingual field entries.

The cites are really to two completely separate works, connected by the fact that one is a translation of another. That's the old hierarchical items bug-bear, and there seems to be a growing sense (correct me if I'm wrong) that covering these cases with extra fields in a single item is an acceptable interim solution.

I've been trying the MLZ and that's not what I need.

For translated works, my Handbook of Style asks for some information (original title, date, edition, language, and, eventually, publisher and publisher place; see my example above); but perhaps other Handbooks want, say, original # of pages, original-series, etc.

I wonder if it is possible to relate items in Zotero with the special characteristic of "original" (obviously, only one item can be the original of another).
So, in every variable of the CSL, in a Citation Style, could be prefixed the word "original-", and Zotero will serve, from its database, not the content of a field named (say) "original-title" but the content of the "title" field of the "original" item.
In this way, every Style would have all the information of the original item (including my requested original "edition", and "language"), and there would be no need to add:
- In the Zotero "Info" tab, then new fields (and in the Syncing code).
- In the (translated) item, one by one, the information (from the original) that every Style could need.
- In the CSL, the new "original-whatever" variables.
- In the forums, a new discussion of the convenience of every single "original-whatever" field requested.

I know that this is not a simple change, but I'm sure it could be useful. (And, I presume, this is easier than the hierarchical issue).

OR

If the above suggestion is rejected, and the option of adding new "original-X" variables and fields is preferred, it could be easy to implement in Zotero the possibility of automatically fill-in the "original-X" fields in an item, by manually selecting another item as the "original". So, the content of the "title" field of the original would be copied in the "original-title" field of the translated, then "date" in the "original-date", and so on.

Item type changes or additions in Zotero are a major undertaking - the data structure needs to change, sync needs to be assured to work, the CSL project - which isn't limited to Zotero - needs to change, too. The hope is to get this into Zotero 3.5

we'll definitely do something about music scores. I'm still not sure how best to do it - just adding an item type with a lot of new fields has its downsides - but we'll try to improve this as much as possible.

In case it's useful to someone, I've built a Python module as part of the work on the book that extracts Zotero-to-CSL mappings. It could be extended a bit (by someone) to provide something nicer and more complete than http://gsl-nagoya-u.net/http/pub/csl-fields.

The code is here:

https://bitbucket.org/fbennett/zoterofieldmap/overview

Frank

It's not just a matter of running a script, unfortunately; the sources have changed since those pages were generated. The new Python module that I linked to above provides more complete mappings. I posted it in case someone might be willing to help the cause by using it to build a better set of mappings. Going forward, the material should really be hosted on zotero.org somehow. If someone can work up a set of templates that work there, I can look at populating an area on the site when I have time.